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

[Crispin Cowan <crispin@novell.com>]

Arjan van de Ven wrote:
> I actually posted a list of 10 things that I made up in 3 minutes; just
> going over those 10 would be a good start already since they're the most
> obvious ones..
>   
I had actually posted a response to those 10 questions in the previous
"remove LSM" thread. Here it is again.

> after all what does filename mean in a linux world with
> * hardlinks
If the policy lets you access /foo/bar/baz then you get to access
/foo/bar/baz, even if it is a hard link to /foo/bif.

Some would allege that this is a security "hole" in AppArmor. However,
AppArmor's design is that you only get to *create* that hard link if you
are either unconfined or your profile says you get to create it.
AppArmor implicitly trusts all non-confined processes, so anything they
do is ok, by definition.

> * chroot
In the currently shipping AppArmor that comes with SUSE Linux, the names
AppArmor sees are chroot-relative. The patch just posted fixes that and
the names AppArmor sees are now absolute, regardless of chroot jailing.

> * namespaces
> * bind mounts
As far as we know, our namespace support is fine; we mediate attempts to
modify namespaces (such as denying mount and umount) and requiring
cap_sys_chroot to modify the root of the namespace. If there are
instances where we are incorrect we would greatly appreciate a detailed
description of the issue (or better a testcase) so we can look at
resolving it.

> * unlink of open files
> * fd passing over unix sockets
AppArmor initially validates your access at open time, and there after
you can read&write to it without mediation. AppArmor re-validates your
access if policy is reloaded, you exec() a new program, you get passed
the fd from another process, or you call our change_hat() API.

So, if the file is unlinked or renamed while you have it open, and
policy says you don't have access to the new name, then:

    *  within the same process you get to keep accessing it until
          o  policy is reloaded by the administrator
          o  you call the change_hat() API
    *  in some other process, either a child or some process you passed
      an fd to, you don't get to access it because your access gets
      revalidated

Note that d_path still returns pathnames for files that have been
removed from the filesystem (that are open)
> * relative pathnames
If you access "../hosts.allow" AppArmor will canonicalize your path name
to /etc/hosts.allow before checking the policy.

> * multiple threads (where one can unlink+replace file while the other
> is in the validation code)
Can you show a specific case that you think would be a problem? Security
is the problem of allowing "good stuff" and blocking "bad stuff", and
that is hard to argue for complex cases that are not specific.

Crispin
-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com