Linux security non-modules and AppArmor [LWN.net]

Linux security non-modules and AppArmor

Posted Jun 28, 2007 16:34 UTC (Thu) by akumria (subscriber, #7773)
In reply to: Linux security non-modules and AppArmor by jamesm
Parent article: Linux security non-modules and AppArmor

One key concept with this framework is that it is "policy flexible". That is, it implements a clean separation of mechanism and policy.

I actually think this is a big problem with SELinux. As far as I know — and I could be wrong but that's never stopped me before! — the kernel is fairly inflexible with that what the superuser uid must be (i.e. 0).

So, why shouldn't there be an "in-kernel" RBAC security policy, or an "in-kernel" TE (Type Enforcement) security policy implemented directly on-top of LSM.

Your recent patch to disallow unloading of security modules give rise to the question, to me anyway, as to why anyone would want to have RBAC and TE security policy implemented at the same time.

Thanks, Anand

(Log in to post comments)

Linux security non-modules and AppArmor

Posted Jun 28, 2007 18:53 UTC (Thu) by jamesm (guest, #2273) [Link]

Traditional DAC is based on an extremely simple binary notion, where euid==0 represents full privilege. The semantics of this are clear, and indeed, this policy may be hard-coded into the kernel.

Beyond DAC (which is definitely inadequate for today's computing environment), the models and their semantics become more complicated. With this complexity, it's important to maintain a separation of mechanism and policy (as a general principle, too), so that different sets of requirements can be met. The policy-flexible design in SELinux arose directly from unsatisfactory experiences with earlier MAC security schemes where policy was hard-coded into the mechanism. In particular, it's been extremely rare to see "trusted" Unix systems in anything other than very specialized situations such as handling classified information.

Policy-flexibility is one of the characteristics of SELinux which makes it suitable not only for these situations, but also for general purpose computing such as a web server or cell phone. This is with no code changes, just different policies loaded.

I'd suggest reading some SELinux docs for more detailed background on the design and its rationale.

e.g. http://www.nsa.gov/selinux/papers/ottawa01/index.html

(the introduction is very useful).