Messages in this thread | | | Date | Tue, 25 Apr 2006 09:00:36 -0700 (PDT) | From | Casey Schaufler <> | Subject | Re: [RFC][PATCH 0/11] security: AppArmor - Overview |
| |
--- James Morris <jmorris@namei.org> wrote:
> You are conflating the policies provided with > SELinux systems with the > mechanisms of SELinux.
You have defeated me. My unabridged Webster does not define "conflating" or even conflat, and I guess that I'm too unhip to be up on it's modern usage. Before I disagree with you, I'd like to know what I've been charged with!
> One of the important features of SELinux is its > policy flexibility, with > clean separation of policy and mechanism.
Except that every single time I'm meet with SELinux developers they have emphasised how important it is to use the Official Policies.
> SELinux provides the mechanisms > to control all security relevant access of processes > to data, and accesses between processes.
Truth.
> It is up to the policy to determine how much of that > mechanism is > utilized, according to desired security goals.
Yes. And a complete system policy is enormous. 500,000 rules and growing, last I heard.
> Targeted policy in fact does perform a > usability-security tradeoff (as all > real security systems must do),
In Orange Book terms this was known as policy not applying to all objects.
> aimed at the relatively simple case of > protecting systems with a few internet facing > services. This is the > default policy shipped with _millions_ of Fedora and > RHEL systems, and > represent, to the best of my knowledge, the first > ever releases of general > purpose operating systems with MAC enabled by > default.
Except that MAC is NOT enabled by default, it is available by default. Only those programs and objects identified by the policy are constrained.
> The aims and limitations of targeted policy are very > well documented.
I'm old, so I won't say they're "very well" documented, but they are documented. The limitations of the targeted policy rarely show up in the glossy, however.
> If you wished, you could load a simpler policy which > can offer an > equivalent level of protection offered by non-MAC > schemes such as > AppArmor. In fact, some work has been going on more > generally in this > area in Japan during the last couple of years.
Yup. The policy description would still be large.
> Other types of users will want stricter policies, to > meet their security > goals. The SELinux mechanism is general enough to > cater to very high > levels of protection and assurance.
Yes it is. It works, I admit. There are even applications I'd suggest it be used for.
> So, please, consider that the mechanism of SELinux > is quite separate from > the types of policies which may be deployed.
Can't do that. The mechanism require large, complex policies.
> And that arguments regarding SELinux "complexity" > often confuse these > issues, as well as issues around tools and > abstractions presented to > users.
The underlying mechanisms are more complex than Bell & LePadula MAC + Biba Integrity + POSIX Caps.
I am not trying to knock SELinux (too hard) in this discussion. I do want to point out that many of the arguements being used against alternatives apply to SELinux as well. I do not understand why SELinux developers feel so threatened by alternatives.
Casey Schaufler casey@schaufler-ca.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |