Some Concrete AppArmor Questions - was Re: [RFC][PATCH 0/11] security: AppArmor - Overview

[Neil Brown <neilb@suse.de>]

I feel we have reached the stage where the questions/comments being
made are actually directly relevant to AppArmor.  I'm afraid I cannot
proceed any further now because I am not a security expert.

I would like to summarise what I think are the key points that you
have raised, and hope that someone who has a deeper understanding of
these things might answer them, or point to answers.

1/ Does AppArmor's primary mechanism of confining an application to a
  superset of it's expected behaviour actually achieve its secondary
  gaol of protecting data?

  Possibly it would be better to ask "When does ..."  as I think it is
  easy to imagine application/profile pairs that clearly cannot allow
  harm, and application/profile pairs that clearly could allow harm.

2/ What advantages does AppArmor provide over techniques involving
   virtualisation or gaol mechanisms?  Are these advantages worth
   while?

3/ Is AppArmour's approach of using d_path to get a filename from a
   dentry valid and acceptable?  If not, how can it get a path?  Can
   suitable hooks be provided so that AppArmor can get a path in an
   acceptable way at the times when that is meaningful?

I believe that these are all good questions.  The last one is the only
one that it really relevant to linux-kernel I believe, however answers
to the first two might tell us how important it is to answer that last
one. 

Thanks for your input.

NeilBrown


.... yes, I am top posting.  The mail I am responding to is below.  I
have not added any commentary in there but have left it for easy
reference so you, dear readers, can decide for yourself whether the
questions I have provided above are relevant to the preceding
discussion.

On Tuesday April 25, sds@tycho.nsa.gov wrote:
> On Tue, 2006-04-25 at 18:10 +1000, Neil Brown wrote:
> > But objects aren't the point.  Paths are.
> > The primary goal of AppArmor isn't to protect objects.
> 
> Ok, please document this throughout all AppArmor documentation and
> literature.  It will be a source of great encouragement to users.
> 
> >   That is
> > secondary.  The primary goal is to stop applications from
> > doing things that they weren't intended to do.  i.e. it is to watch
> > their behaviour and make sure it doesn't deviate from what is
> > intended.
> 
> What is intended goes beyond what names are used - it involves the
> actual objects.  When /bin/su asks to open /etc/shadow, it wants the
> real system shadow password file, not just any old file to
> which /etc/shadow might happen to resolve.  Further, even at this
> "primary" goal, AppArmor does a poor job wrt to already existing
> virtualization or jail mechanisms AFAICS.  
> 
> > This will largely have the effect of protecting data, as protecting
> > data is the intended secondary effect of AppArmor's primary mechanism
> > which is behaviour control.
> 
> No, it won't protect the data.  You can't have it both ways.  Either you
> are only controlling the use of paths and not concerned with the objects
> (if so, please document as such, but I can't imagine Crispin et al
> admitting to such a position), or you are controlling the objects and
> thus protecting the data.  
> 
> > I think this text is fairly vague, and could be taken to mean several
> > things. 
> > I think the policies do define what resources can be accessed and does
> > it using names.  "Anything with name X can be accessed".  Note that
> > AppArmor profiles never say what cannot be accessed, only what can.
> 
> Um, that's problematic then.  If I can't determine what cannot be
> accessed, then I can never know whether I have achieved my protection
> goals.
> 
> > In that sense they are not primarily protecting things so in a sense
> > they are not protecting any given file.  Nevertheless the net result
> > is an increased level of data protection.
> 
> No, only the appearance of it.
> 
> > Maybe the documentation could be improved - that wouldn't be an
> > uncommon situation.
> 
> Dollars to donuts that they won't be willing to document that AA doesn't
> protect objects in their documentation.
> 
> > > If it isn't, then is anyone and everyone free to introduce other
> > > path-based mechanisms in the kernel in the future?  Why has that been
> > > frowned upon in the past if there really isn't anything wrong with it?
> > 
> > "path-based mechanisms" like open, unlink, mkdir, ....
> > There are plenty of these in the kernel.
> 
> Pathname resolution is fine, obviously.  Regenerating pathnames in the
> kernel and using them as part of your mechanism is...interesting.  Don't
> confuse the userspace configuration and kernel-user interface with the
> internal mechanisms.  Should inotify be calling d_path internally for
> reporting to userspace?  
> 
> > "path-based mechanisms" like "You cannot truncate a file named /etc/shadow"?
> > No, that would not be appropriate in the kernel as it is not well
> > defined.
> 
> That is precisely what AppArmor does.
> 
> > However AppArmor doesn't (or shouldn't) do this.  It might say  "You
> > cannot truncate a file that you found by looking up the name
> > /etc/shadow", and I think that would be a valid and useful thing to
> > do.
> 
> AA doesn't even do that - as most of the LSM hooks don't get the
> vfsmount info propagated to them, they don't know what specific path
> your application took to the file.  
> 
> >   It might not do what you want, but that all depends on what you
> > want.   The things you can ask AppArmor to do are still useful and
> > meaningful even if they are not the things that you might ask SELinux
> > to do.
> 
> I don't see why you wouldn't use a jail-style mechanism if that is what
> you want.
> 
> -- 
> Stephen Smalley
> National Security Agency
> 
> -
> 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/
-
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/