Re: AppArmor FAQ

[James Morris]

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
<jmorris@xxxxxxxxx>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/