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

[Stephen Smalley <sds@tycho.nsa.gov>]

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/