| |||||||||||||
Kernel Summit 2006: SecurityKernel Summit 2006: SecurityPosted Jul 20, 2006 23:39 UTC (Thu) by crispin (guest, #2073)In reply to: Kernel Summit 2006: Security by Method Parent article: Kernel Summit 2006: Security
"... the Flask architecture within
So it is not true that Flask can support *any* kind of security server. In particular, Flask cannot support the AppArmor model.
There are 13 known modules built on top of LSM, and AFAIK the only models built on top of Flask are those that Method quoted. This would seem to argue that LSM is both more general and more useful.
LSM is not perfect, and we (Novell/SUSE) would be happy to work with anyone who is interested in improving it, so long as "improve" includes at least preserving its current generality (ability to support these security models). This is the whole reason LSM exists; so that the Linux community does not have to choose One True Security Model, because the security community itself has never agreed on a model.
(Log in to post comments)
Kernel Summit 2006: Security Posted Jul 21, 2006 0:55 UTC (Fri) by Method (guest, #26150) [Link] You are right, Flask has successfully implemented the security models that have been around for decades and are tried and true.
Arbitrary security policies are just that. Consider the LSM implementation of securelevels that ended up being more insecure than not having it. Then consider the limitations and bypassability of Apparmor as I explained at http://securityblog.org/brindle/2006/04/19/security-anti-....
If its a choice between reasonable (and working) security models and arbitrary ones that have severe security issues and limitations I'll take Flask.
There might not be a One True Security Model in the security community but quote honestly apparmor isn't even a contestant.
Kernel Summit 2006: Security Posted Jul 22, 2006 18:50 UTC (Sat) by nix (subscriber, #2304) [Link] 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) [Link] Comprehensively? Hardly.
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.
Kernel Summit 2006: Security Posted Jul 24, 2006 16:13 UTC (Mon) by crispin (guest, #2073) [Link] ... 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?
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.
|
|||||||||||||