Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

On Sun, Jun 10, 2007 at 10:09:18AM -0700, Crispin Cowan wrote:
Andreas Gruenbacher wrote:
On Saturday 09 June 2007 02:17, Greg KH wrote:

On Sat, Jun 09, 2007 at 12:03:57AM +0200, Andreas Gruenbacher wrote:

AppArmor is meant to be relatively easy to understand, manage, and
customize, and introducing a labels layer wouldn't help these goals.

Woah, that describes the userspace side of AA just fine, it means
nothing when it comes to the in-kernel implementation. There is no
reason that you can't implement the same functionality using some
totally different in-kernel solution if possible.

I agree that the in-kernel implementation could use different abstractions
than user-space, provided that the underlying implementation details can be
hidden well enough. The key phrase here is "if possible", and in fact "if
possible" is much too strong: very many things in software are possible,
including user-space drives and a stable kernel module ABI. Some things make
sense; others are genuinely bad ideas while still possible.

In particular, to layer AppArmor on top of SELinux, the following
problems must be addressed:

* New files: when a file is created, it is labeled according to the
type of the creating process and the type of the parent directory.
Applications can also use libselinux to use application logic to
relabel the file, but that is not 'mandatory' policy, and fails in
cases like cp and mv. AppArmor lets you create a policy that e..g
says "/home/*/.plan r" to permit fingerd to read everyone's .plan
file, should it ever exist, and you cannot emulate that with SELinux.

A daemon using inotify can "instantly"[1] detect this and label the file
properly if it shows up.

* Renamed Files: Renaming a file changes the policy with respect to
that file in AA. To emulate this in SELinux, you would have to
have a way to instantly re-label the file upon rename.

Same daemon can do the re-label.

* Renamed Directory trees: The above problem is compounded with
directory trees. Changing the name at the top of a large, bushy
tree can require instant relabeling of millions of files.

Same daemon can do this. And yes, it might take a ammount of time, but
the times that this happens in "real-life" on a "production" server is
quite small, if at all.

* New Policies: The SEEdit approach of compiling AA profiles into
SELinux labels involves computing the partition set of files, so
that each element of the partition set is unique, and corresponds
to all the policies that treat every file in the element
identically. If you create a new profile that touches *some* of
the files in such an element, then you have to split that
synthetic label, re-compute the partition set, and re-label the
file system.

Again, same daemon can handle this logic.

* File Systems That Do Not Support Labels: The most important being
NFS3 and FAT. Because they do not support labels at all, SELinux
has to give you an all-or-nothing access control on the entire
remote volume. AA can give you nuanced access control in these
file systems.

SELinux already provides support for the whole mounted filesystem,
which, in real-life testing, seems to be quite sufficient. Also, the
SELinux developers are working on some changes to make this a bit more
fine-grained.

See also Stephan's previous comments about NFSv3 client directories and
multiple views having the potential to cause a lot of havoc.

You could support all of these features in SELinux, but only by adding
an in-kernel file matching mechanism similar to AppArmor.

I don't think that is necessary at all, see above for why.

It would basically load an AppArmor policy into the kernel, label
files as they are brought from disk into the cache, and then use
SELinux to do the access controls.

No, do the labeling in userspace with a daemon using inotify to handle
the changing of the files around.

Or has this whole idea of a daemon been disproved already with a
prototype somewhere that failed? If not, a simple test app would not be
that hard to hack up. Maybe I'll see if I can do it during the week of
June 24 :)

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages