On Friday April 21, [email protected] wrote:
> On Fri, 2006-04-21 at 10:30 -0700, Chris Wright wrote:
> > * Stephen Smalley ([email protected]) 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 [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]
