Messages in this thread | | | From | Neil Brown <> | Date | Mon, 24 Apr 2006 14:18:50 +1000 | Subject | Re: [RFC][PATCH 0/11] security: AppArmor - Overview |
| |
On Friday April 21, sds@tycho.nsa.gov wrote: > On Fri, 2006-04-21 at 10:30 -0700, Chris Wright wrote: > > * Stephen Smalley (sds@tycho.nsa.gov) wrote: > > > Difficult to evaluate, when the answer whenever a flaw is pointed out is > > > "that's not in our threat model." Easy enough to have a protection > > > model match the threat model when the threat model is highly limited > > > (and never really documented anywhere, particularly in a way that might > > > warn its users of its limitations). > > > > I know, there's two questions. Whether the protection model is valid, > > and whether the threat model is worth considering. So far, I've not > > seen anything that's compelling enough to show AppArmor fundamentally > > broken. Ugly and inefficient, yes...broken, not yet. > > Access control of any form requires unambiguous identification of > subjects and objects in the system. Paths don't achieve such > identification. Is that broken enough? If not, what is? What > qualifies as broken?
I have to disagree with this. Paths *do* achieve unambiguous identification of something. That something is ..... the path.
Think about the name of this system for a minute. "AppArmor". i.e. it is Armour for an Application. It protects the application. It doesn't (as far as I can tell: I'm not an expert and don't work on this thing) claim to protect files. It protects applications.
It protects them from doing the wrong thing - from doing something they weren't designed to do. i.e. it protects them from being subverted by exploiting a bug.
A large part of the behaviour of an application is the path names that it uses and what it does with them. If an application started doing unexpected things with unexpected paths (e.g. exec("/bin/sh") or open("/etc/shadow",O_RDONLY)) then this is a sure sign that it has been subverted and that AppArmor need to protect it, from itself.
Obviously the protection will not be complete. The profiles describe what the application is expected to do, and to some extent, this description will be in general terms. It might identify files that can be written to, but not what will be written to them. etc.
While the protection against subversion cannot be complete, it can be sufficient to dramatically reduce the chances of privilege escalation. There are lots of wrong things you can get an application to do once you find an exploitable bug. Many of these will lead to a crash. AppArmor will not try to protect against these (I suspect). There are substantially fewer that lead to privilege escalation. AppArmor focusses its effort in terms of profile design on exactly these sorts of unplanned behaviours.
So I think you still haven't given convincing evidence that AppArmor is broken by design.
NeilBrown - 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/
| |