Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
It's odd that all the points you raise in this comment are ones which Mike Hearn comprehensively demolished in his comment to the very post you link to.
Kernel Summit 2006: Security
Posted Jul 22, 2006 19:07 UTC (Sat) by Method (guest, #26150)
He responded to 3 of the points, (thats out of 11 since you appear to have problems counting).
I chose not to respond to his comment because I don't want huge comment threads on my blog (I'd rather respond in another post, and have people respond to my blog on theirs).
But since you brought it up.. The responses were also not comprehensive, the paths are ambiguous response only covered hard links (claiming that they weren't common) and ignored chroots, namespaces and bind mounts by saying only root can do them, hardly a compelling argument.
The response about not everything being a path: His response was to make fake paths for things not on the filesystem.. What a great idea! Show me how to differenciate shared memory from 2 processes run from the same binary. He also apparently thinks the policy should understand http semantics, not compelling at all.
Last his argument about lack of object tranquility shows a thorough misunderstanding for why object tranquility is important to security.
In short I think most of my readers could easily see that the arguments were weak, I didn't need to respond.
Posted Jul 24, 2006 16:13 UTC (Mon) by crispin (guest, #2073)
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:
Path ---- File
Label ---- 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?
Posted Jul 24, 2006 17:01 UTC (Mon) by Method (guest, #26150)
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.
Posted Jul 24, 2006 20:12 UTC (Mon) by nix (subscriber, #2304)
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)
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.]
Posted Jul 25, 2006 21:04 UTC (Tue) by dlang (✭ supporter ✭, #313)
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds