LWN: Comments on "Kernel Summit 2006: Security"

Kernel Summit 2006: Security

dlang — 2006-07-25T21:04:38+00:00

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

roelofs — 2006-07-25T03:43:57+00:00

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

AppArmor and chroot

sweikart — 2006-07-24T23:51:50+00:00

> 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

nix — 2006-07-24T20:12:40+00:00

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*.

Kernel Summit 2006: Security

Method — 2006-07-24T17:01:44+00:00

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

crispin — 2006-07-24T16:13:50+00:00

... 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

Method — 2006-07-22T19:07:14+00:00

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

nix — 2006-07-22T18:50:42+00:00

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

Method — 2006-07-21T00:55:42+00:00

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

crispin — 2006-07-20T23:39:57+00:00

"... the Flask architecture within
SELinux, 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

Method — 2006-07-19T11:45:48+00:00

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

nix — 2006-07-19T10:19:08+00:00

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

flewellyn — 2006-07-19T06:32:15+00:00

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

dang — 2006-07-19T03:24:38+00:00

"Stephen noted that LSM has little use for SELinux, that things could work just as well without it"

Other way 'round?