Kernel Summit 2006: Security [LWN.net]

Kernel Summit 2006: Security

Posted Jul 24, 2006 16:13 UTC (Mon) by crispin (guest, #2073)
In reply to: Kernel Summit 2006: Security by Method
Parent article: Kernel Summit 2006: Security

... so lets take just one argument at a time: "paths are ambiguous".

Hmmm. Yes, more than one path name can refer to a single file. This would be a problem in a black-list system, in which you try to name all the files you cannot access. But AppArmor is a white list system that names the files you can access. So if policy grants you access to /etc/shadow, it doesn't matter if /tmp/mumblebarf also points to the same place.

If policy grants you access to /tmp/* and someone created an alias so that /tmp/mumblebarf points to /etc/shadow, then they must have had the privileges necessary to create such a powerful alias.

On the other hand, pathnames are unambiguous in that a give pathname always points exactly to a single file.

Now lets look at labels. A file can have only a single label. So all policies that want to grant access to a given file have to grant access to that label.

OTOH, many different files can have the same label. So it is difficult for a policy to grant access to just that specific file; you have to grant access to its label, and that also grants access to all the other files that have that same label.

Visually, it looks like this:

Pathnames:

Path -\
       \
Path ---- File
       /
Path -/

Labels:

        /- File
       /
Label ---- File
       \
        \- File

So if you ever find yourself in the position of wanting to grant an access to *some* of the files that share a label and not others, then you would have to re-label them all with some new labels that distinguish as such, and then go change all of the policies that use that label to then use the new 2 or more labels.

Oh, and this blows your object tranquility because it requires re-labeling. Unless you anticipated all possible such scenarios and got your labels *perfect* the first time.

So which kind of ambiguity do you prefer?

(Log in to post comments)

Kernel Summit 2006: Security

Posted Jul 24, 2006 17:01 UTC (Mon) by Method (guest, #26150) [Link]

I'm actually not going to go through this in LWN comments, its very unproductive. However, you had one entirely false statement in your comment:
"On the other hand, pathnames are unambiguous in that a give pathname always points exactly to a single file."

That is absolutely incorrect, as I pointed out in my blog entry and in previous email discussions a single path (eg., /etc/shadow) can refer to "/etc/shadow" in any namespace (chroots or private namespaces).

The great thing about this is that, for example, your bind "policy" gives access to /.* (that means any file on the filesystem), because it is assumed that bind is chrooted.

It doesn't take a genius to figure out that this is incredibly bad if bind fails to chroot, or if someone changes its configuration, etc.

This shows very clearly that apparmor is essentially a "fail open" security mechanism which is the worst possible thing from a security standpoint (particularly since the user won't even find out).

The alternative labeled security systems fail closed so if bind couldn't chroot it doesn't matter, it can't access anything on the system.

Anyway, thats it for my responses here, there are far more productive ways of relaying this information than through comments. ciao.

Kernel Summit 2006: Security

Posted Jul 24, 2006 20:12 UTC (Mon) by nix (subscriber, #2304) [Link]

It doesn't take a genius to grasp that AppArmor counters this by banning namespace changes (other than chroot(), which can be handled) for covered applications. Yes, this means no fancy shared subtree hacks can be carried out by apps that are *actually covered*, but since shared subtree hacks are often done by login PAM modules, and that's not going to be stuff you're going to protect with AppArmor...

You continue to complain that AppArmor is useless because it doesn't try to protect absolutely everything all of the time, even though *this was a design goal*.

AppArmor and chroot

Posted Jul 24, 2006 23:51 UTC (Mon) by sweikart (guest, #4276) [Link]

> The great thing about this is that, for example, your bind
> "policy" gives access to /.* (that means any file on the
> filesystem), because it is assumed that bind is chrooted.
> ... This shows very clearly that apparmor is essentially a
> "fail open" security mechanism

If 'bind' is configured to chroot to e.g. /chroot/bind, then it seems like a mistake to have bind's AppArmor policy specify pathname-access with /.*; it seems like the policy should specify "real" path names, i.e. /chroot/bind/* . This way, AppArmor apps would "fail closed" rather then "fail open". [This methodology might also work with namespace changes.]

-scott

Kernel Summit 2006: Security

Posted Jul 25, 2006 21:04 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]

and the reply to this by AppArmor was that they are enhancing AA to look at the path to the file looking through the namespace mappings.

so you wouldn't have a policy that granted /.* to bind, you would have a policy that granted /chroot/.* to bind. thus if bind fails the chroot it would have no access to anything that it wouldn't have access to if the chroot suceeded (and it would then fail miserably since nothing was where it expected)

yes this was a real issue, but it's also a straightforward one to resolve.