Kernel Summit 2006: Security
| 2006 Kernel Summit coverage on LWN.net. |
The LSM interface has been in the mainline for five years now, and there is still only one in-tree user: SELinux. That fact might argue for the removal of LSM as an unneeded abstraction layer, but there are other security policies out there which have been proposed for inclusion. At the head of the line is AppArmor, which was recently acquired and open-sourced by Novell. Tony Jones argued that this code is shipped with SUSE Linux, and it is used by real people who actually like it. It is, he thinks, a suitable addition to the kernel.
AppArmor, says Tony, is focused on network-based threats. It is intended to protect servers, and to enable fast, easy policy development. This claim drew the first objection: Christoph Hellwig noted that security is never easy. Rather than trying to come up with an easy fix via a security framework, he said, developers should be getting server applications right and "fix the crappy code." The response was that crappy code will always exist, but that it would be nice to have reasonably secure systems anyway.
The real issue with AppArmor, however, is its use of pathnames in the definition of security policies. To many people in the security field, pathnames are an insecure mechanism for this task. To drive this point home, Stephen Smalley put up a slide entitled "pathname-based mechanism considered harmful"; his purpose was clearly to oppose the inclusion of AppArmor. Anything based on pathnames, says Stephen, is inherently nondeterministic - not a nice feature in a security system.
Not everybody agrees with that point of view, however. In the end, pathnames are how people and programs find files - in some way, they are the file just as much as the inode is. A program looking for account information will open /etc/passwd without caring much which inode is behind it. Developers who see things this way (and Linus is one of them) do not think that AppArmor should be blocked because of its use of pathnames.
Besides, there is a way to address the biggest objection to pathname-based policies: that they can be circumvented by creating a new link (and, thus, a different path) to a restricted binary. If the ability to create such links is controlled, the problem goes away. AppArmor does attempt to impose this sort of control; it could be strengthened by adding a "links to this file cannot be created" permission bit somewhere.
As one might expect, this discussion went around the room for some time without generating much consensus. There is a sizeable group of kernel developers who feel that AppArmor should be allowed into the kernel. Linux supports an amazing variety of filesystems, some of which were described as "demented." Certainly there must be room for a security policy which some people find useful. Others, however, remain strongly in opposition to the merging of AppArmor.
Toward the end, attention was forcibly redirected to the problem of what to do about the LSM framework. Stephen noted that SELinux has little use for LSM, that things could work just as well without it. Tony said that AppArmor needed LSM, that there was no way to implement it on top of the lower layers of SELinux, as has been suggested by some developers. Linus said that the entire reason that LSM had been added was to avoid having this sort of discussion every year. The fact that the security policy discussion only returned when the removal of LSM was threatened sort of backs up that point.
The end result, as expressed by Linus, is that LSM will remain in the kernel. Since there is no prospect of a consensus on the One True Security Policy, there needs to be a way to support more than one of them. A more interesting discussion might have been the often-threatened rewrite of LSM to provide a better, more restricted set of operations, but there was no time for that here.
| Index entries for this article | |
|---|---|
| Kernel | AppArmor |
| Kernel | Modules/Security modules |
| Kernel | Security/Security technologies |
| Kernel | SELinux |
(Log in to post comments)
Kernel Summit 2006: Security
Posted Jul 19, 2006 3:24 UTC (Wed) by dang (guest, #310) [Link]
"Stephen noted that LSM has little use for SELinux, that things could work just as well without it"
Other way 'round?
Kernel Summit 2006: Security
Posted Jul 19, 2006 6:32 UTC (Wed) by flewellyn (subscriber, #5047) [Link]
Not necessarily; it's a somewhat odd construction, but "has use for" could be construed to mean"is useful to", as in "that has little use for me".
It's rather archaic, but I've seen the phrasing used in some older (read: Victorian and earlier)
texts.
Kernel Summit 2006: Security
Posted Jul 19, 2006 10:19 UTC (Wed) by nix (subscriber, #2304) [Link]
It's notable that the SELinux developers have been appearing to say that there *was* a way to implement AppArmor atop SELinux, and indeed everything else security-related one could possibly imagine that was any use to anyone, and that therefore LSM was unnecessary.
It always struck me as the sort of thing that was *bound* to be proved wrong.
Kernel Summit 2006: Security
Posted Jul 19, 2006 11:45 UTC (Wed) by Method (guest, #26150) [Link]
SELinux is implemented under a framework called Flask (http://www.cs.utah.edu/flux/fluke/html/flask.html). It abstracts the details of the underlying hooks from the security server (which just cares about giving the requested decision).
LSM also does this but in a less useful way (they are only hooks with no kind of infrastructure whatsoever). So SELinux does not need LSM because Flask already provides the same thing.
That said, Flask can support any kind of security server, in fact several security models are implemented in SELinux' security server, RBAC (of sorts), Type Enforcement (the main SELinux security model) and MLS (Multi-level security, classic Trusted OS MAC)
Kernel Summit 2006: Security
Posted Jul 20, 2006 23:39 UTC (Thu) by crispin (guest, #2073) [Link]
"... the Flask architecture withinSELinux, which establishes a framework with well-defined semantics that
can support a wide range of security models, but not arbitrary ones." --Stephan Smalley, http://lkml.org/lkml/2006/4/20/110
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.
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 (guest, #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.
Kernel Summit 2006: Security
Posted Jul 25, 2006 3:43 UTC (Tue) by roelofs (guest, #2599) [Link]
Christoph Hellwig noted that security is never easy. Rather than trying to come up with an easy fix via a security framework, he said, developers should be getting server applications right and "fix the crappy code." The response was that crappy code will always exist, but that it would be nice to have reasonably secure systems anyway.Hellwig's comment seems a bit naive. And while the response to it is valid as far as it goes, I would word it more strongly: (1) "security is never easy" doesn't mean it should be harder than necessary (i.e., don't whitewash the risks, but don't throw up unnecessary obstacles for less technically adept users, either); and (2) as a rule of thumb, security is never about "rather than"--it's about "in addition to". That is (regarding item 2), you don't ignore privilege-escalation issues just because you believe remote execution is blocked; you address both. You don't stop working on security just because you've got a corporate firewall and DMZ in place; you also harden your kernels, your apps, your facility, your procedures, and your users(!).
That said, I don't have a particular axe to grind with respect to either SELinux or AppArmor; I've never used either one, personally. But if I were still running servers at home, I think I'd be more inclined to start with AppArmor, based solely on what I've read here...
Greg