Linus Torvalds <[email protected]> writes:
> To get back to security: I didn't want pluggable security because I
> thought that was a technically good solution. No, the reason Linux has LSM
> (and yes, I was the one who pushed hard for the whole thing, even if I
> didn't actually write any of it) was because the problem wasn't technical
> to begin with.
>
> It was social/political and administrative.
>
> See? Another fundamental difference between schedulers and security
> modules.
>
> But no, that's not really why we have LSM. I'd have *much* preferred to
> have one unified security module setup that we could all agree on, and no
> pluggable security modules. It was not to be - and the reason we have LSM
> is not because "it makes more sense than a CPU scheduler", but simply
> because "people didn't actually get anything done at all, because they
> just argued about what to do".
>
> In the CPU schedulers, Ingo still gets work done, even though people argue
> about it. So we haven't needed to go to the extreme of an "LSM for CPU
> schedulers", because the arguments don't actually hold up the work.
>
> And THAT is what matters in the end.
Sounds good.
I want to inject some fresh ideas into this discussion from a completely
different viewpoint, who knows I might get lucky and make things
better.
All you can do with the LSM is return -EPERM when the normal unix
permissions would not have allowed an operation. I don't see where
there is any magic or mystery in that, or any need for deep
understanding.
What we want from the LSM is the ability to say -EPERM when we can
clearly articulate that we want to disallow something.
SElinux is not all encompassing or it is generally incomprehensible I
don't know which. Or someone long ago would have said a better
way to implement containers was with a selinux ruleset, here is a
selinux ruleset that does that. Although it is completely possible to
implement all of the isolation with the existing LSM hooks as Serge
showed.
It is a legitimate criticism of the LSM that we are not improving our
in-kernel abstractions to allow better concepts to base decisions
upon when to return -EPERM. My first dealing with selinux and the lsm
was when I fixed a security issue in /proc fixed the abstractions we
were using and the default selinux security policy had a fit. If
don't have good concepts in /proc/pid/xxx which is heavily used it
would not surprise me at all if there are lots of other places in the
kernel where our abstractions holes that have not yet been shorn up.
We also have in the kernel another parallel security mechanism (for
what is generally a different class of operations) that has been quite
successful, and different groups get along quite well, and ordinary
mortals can understand it. The linux firewalling code.
The linux firewalling codes has hooks all throughout the networking
stack, just like the LSM has hooks all throughout the rest of linux
kernel. There is a difference however. The linux firewalling code in
addition to hooks has tables behind those hooks that it consults.
There is generic code to walk those tables and consult with different
kernel modules to decide if we should drop a packet. Each of those
kernel modules provides a different capability that can be used to
generate a firewall.
Meanwhile composition of a policy using code from different clients
of the LSM hooks is impossible, and thus cooperation or wider use of
the LSM hooks is difficult.
So I propose that if people want to work towards a one true linux
solution for additional security checks, then they should look towards
the linux firewalling code. It works and it seems to very nicely
allow cooperations between different groups. For the people who will
scream mixing security models causes problems, the answer is simple
recommend users don't set up their policies that way.
I know we can't solve human problems with technical measures but
perhaps a technical suggestion can open the way to the solution to
some human problems.
I'm not yet annoyed enough to go implement an iptables like interface
to the LSM enhancing it with more generic mechanism to make the
problem simpler, but I'm getting there. Perhaps next time I'm bored.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
