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/
[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]
