Cc: Bill Davidsen <davidsen@...>, Stephen Smalley <sds@...>, James Morris <jmorris@...>, Andrew Morton <akpm@...>, <casey@...>, <linux-security-module@...>, <linux-kernel@...>, Serge E. Hallyn <serge@...>
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
-
