Re: [RFC][PATCH 0/11] security: AppArmor - Overview

[Joshua Brindle <method@gentoo.org>]

Neil Brown wrote:
> On Friday April 21, sds@tycho.nsa.gov wrote:
> > 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.
>
>   
On the contrary. Due to namespaces a single path can describe many 
different files, depending on the namespace you are in. Same with 
chroots, if an app that is chrooted can read /etc/shadow it can also 
read it outside the chroot. Even if this weren't the case the path isn't 
the object. Objects are 'things' being acted upon by a subject. A path 
is merely an address to an object. A burglar might use your address to 
get to your house but in the end it's your house he's robbing, not the 
address.

> 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.
>   
A large part of protecting applications is protecting which apps can 
interact with those applications, directly or indirectly. Without the 
ability to look at the policy and know if its actually doing what you 
think it is (which you can't with path based access control) you have no 
way of telling whether an application is actually protected. This leads 
to false sense of security.

Another large part of protecting applications is protecting the system 
which supports them. The apparmor crowd will claim that these apps are 
trusted but there are many ways a confined application can indirectly 
influence an unconfined application and most privilege escalation 
attacks are multi-step already thus buying little.

> 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.
>
>   
Sure but if, instead, it's able to open /var/chroot/etc/shadow which is 
a hardlink to /etc/shadow you've bought nothing. You may filter out 
worms and script kiddies this way but in the end you are using obscurity 
(of filesystem layout, what the policy allows, how the apps are 
configured, etc) for security, which again, leads to a false sense of 
security.
> 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.
>
>   
It only reduces the chance to inexperienced and/or lazy hackers ;) . It 
wouldn't take someone experienced to figure out that you have apparmor  
running on the system and thus know how to break/bypass it. Once again, 
false sense of security.
> So I think you still haven't given convincing evidence that AppArmor
> is broken by design.
>   
I haven't heard any responses to any of the ~11ish points brought up at 
http://securityblog.org/brindle/2006/04/19/security-anti-pattern-path-based-access-control/ 
. Its very long but I can paste it into an email if necessary.

In particular I'd love to hear about how Apparmor is so easy to use, 
considering the apparmor crowd advocates things like making hardlinks to 
/bin/bash and setting that new path to a 'restricted' users login shell. 
This is not obvious, secure, scalable or intuitive. I'd hope most 
administrators recognize the severe limitations of this 'solution' and 
opt for something stronger.

Joshua Brindle
-
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/