On Tue, 17 Apr 2007, David Wagner wrote: > be more usable than SELinux. Even if SELinux is more "complete" > than AppArmor, I might still prefer ease of use over completeness > and understandability.
I would challenge the claim that AppArmor offers any magic bullet for ease of use. There are plenty of examples of people disabling it because their apps stop working: http://lists.opensuse.org/opensuse/2006-07/msg02440.html "Suddenly I have to disable AppArmor to start postfix." Sound familiar ? I'd also challenge the idea that the pathname policy scheme is easy enough for users to understand and meaningfully manage. The chief architect of the project can't explain a simple policy he used to demonstrate its simplicity: http://marc.info/?l=full-disclosure&m=114429157431167&w=2 " > but as you posted an example profile with "capability setuid", I must > admit I am curious as to why an email client needs that. Well now that is a very good question, but it has nothing to do with AppArmor. The AppArmor learning mode just records the actions that the application performs. With or without AppArmor, the Thunderbird mail client is using cap_setuid. AppArmor gives you the opportunity to *deny* that capability, so you can try blocking it and find out. But for documentation on why Thunderbird needs it, you would have to look at mozilla.org not the AppArmor pages. " What this is demonstrates is that usability has nothing to do with pathnames or labels, and that the underlying complexity of the system dominates the issue. In this case, the application needs a certain capability -- setuid, no less -- and the user doesn't understand why. At this point, AppArmor loses its claimed transparency, and the user must ultimately understand what the system is doing and why. SELinux, at the lowest level, simply exposes the complexity of the underlying security-relevant interactions of the system for the purposes of control. Usability needs to be addressed at a higher level. Something that is poorly understood is that SELinux policy was never intended to be developed by users. It's like an assembly-language; it provides an extremely low-level mechanism for controlling all security-relevant accesses in the operating system. The solution, as with programming languages (to continue the analogy), is to develop higher-level abstractions to hide the underlying complexity. Good progress has already been made in this area, and more is expected. I certainly don't think the solution is to start out by ignoring the underlying complexity. - James -- James Morris <[EMAIL PROTECTED]> - 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/
