Walsh: Introducing the SELinux Sandbox

Posted May 27, 2009 4:02 UTC (Wed) by spender (guest, #23067)
In reply to: Walsh: Introducing the SELinux Sandbox by Kit
Parent article: Walsh: Introducing the SELinux Sandbox

You really should refrain from using words like "only" (especially emphasized) when talking about what arbitrary code executing in the context of a large piece of software with many dependencies and addons is limited to doing. You didn't mention kernel compromises that disable SELinux in your list of things it's limited to. Take the vmsplice exploit for instance. That exploit required mmap, munmap, pipe, and vmsplice, only 4 things which all processes on the machine were permitted to use. What files of the user the exploit could write to didn't even come into the picture.

-Brad

to post comments

Walsh: Introducing the SELinux Sandbox

Posted May 27, 2009 6:50 UTC (Wed) by hppnq (guest, #14462) [Link] (7 responses)

But in the same thread you say that it might be a good idea to improve the security of the kernel itself. How would patching the kernel help against kernel bugs?

Note that the vmsplice vulnerability needs to be exploited, actually. While it is obvious that this also actually happens, somewhere, this does not mean that we should therefore grab our wands and blow all vmsplice vulnerabilities into oblivion. I think it is rather obvious that it is a better idea to create an architecture that itself can be proven to be more secure than thinking that a random pile of code can ever be made completely secure.

Walsh: Introducing the SELinux Sandbox

Posted May 27, 2009 22:40 UTC (Wed) by spender (guest, #23067) [Link] (6 responses)

I'm a little confused by your post; maybe you can clarify a few things for me:

1) Was the use of "vulnerability" in italics a way of correcting my use of the phrase "vmsplice exploit"? My usage was correct -- I was referring to the actual publicly released exploit for the vulnerability so that I could comment on what system calls were used in it.

2) "How would patching the kernel help against kernel bugs?" Take NULL pointer dereference vulnerabilities as an example. If the kernel is unable to access userland memory directly, then these vulnerabilities become unexploitable for anything but a DoS. Would you not consider that patching of the kernel "help against kernel [vulnerabilities]"?

3) What's this architecture you're referring to? Are you saying the only options are fixing individual bugs or throwing SELinux-level complexity at the problem?

-Brad

Walsh: Introducing the SELinux Sandbox

Posted May 28, 2009 10:29 UTC (Thu) by hppnq (guest, #14462) [Link] (5 responses)

Was the use of "vulnerability" in italics a way of correcting my use of the phrase "vmsplice exploit"?

Err, no. It was meant to stress "vulnerability". Even if an exploit for a vulnerability exists -- and let's just assume this is always the case -- it does not mean that you are also actually vulnerable. This is perhaps the most important part of security management: know your vulnerabilities. I mentioned it because this is something you seem to overlook. There is nothing wrong with that in discussions about specific vulnerabilities, but you are dismissing entire frameworks here.

Would you not consider that patching of the kernel "help against kernel [vulnerabilities]"?

Of course it would help making the kernel more secure. But it will not rule out kernel bugs. What's more: it seems a bad idea to think that any specific part of the kernel is able to protect the kernel.

What's this architecture you're referring to?

The architecture of which, for instance, SELinux is a part. Or grsecurity. Or my shielded network cable. As opposed to saying "this piece of code is secure".

Are you saying the only options are fixing individual bugs or throwing SELinux-level complexity at the problem?

No. I am saying that security follows from principles. A bug-free kernel with a perfect SELinux implementation would still not make most people safe -- whatever "safe" means for them.

Walsh: Introducing the SELinux Sandbox

Posted May 28, 2009 12:48 UTC (Thu) by spender (guest, #23067) [Link] (4 responses)

I never talked about ruling out kernel bugs, you did. I was talking about making the kernel more secure, which involves reducing the number of exploitable vulnerabilities -- specifically by making certain vulnerability classes unexploitable.

"it seems a bad idea to think that any specific part of the kernel is able to protect the kernel." -- I just gave you an example that you agreed makes the kernel more secure. Do you need more examples? I listed them in another post. Why's it such a bad idea to make classes of vulnerabilities unexploitable and thus prevent someone from being able to take advantage of an applicable vulnerability for the purpose of arbitrary code execution in the kernel?

You said that it's a bad idea to think that the kernel can protect itself, but then you go on to say that SELinux is a good way of protecting the kernel (or at least, better than fixing a couple bugs). I agree -- it's better than fixing a couple bugs, but it's the wrong approach for protecting the kernel. And like it or not, a lot of what SELinux bothers itself with is an attempt (either directly or indirectly) to protect the kernel. There's no reason really to restrict some obscure system call that an application doesn't use in any of its code-paths unless you're assuming the possibility of arbitrary code execution. Even then, there's not much point in restricting the obscure system call (there are plenty more useful ones for the attacker that aren't restricted) unless you're trying to reduce the attack surface of the kernel.

It should be clear that using SELinux to try to protect the kernel isn't very successful, especially in the face of remote exploits (as noted earlier). It calls into question the usefulness of the additional complexity required for the vain attempt at keeping attackers either from doing things they don't want to do that they can do in other ways, or from exploiting the kernel. It seems to me that it makes more sense to make classes of vulnerabilities unexploitable. It adds no additional complexity or burden on the user and has demonstrated itself to be more useful against real attacks. Take for instance, as I mentioned in another post, about what's been done in terms of hardening userland applications invisibly -- these kinds of changes (when implemented properly at least) are incredibly useful. In fact, the addition of a protection to SELinux (which really sticks out from its other features, and was contributed by a 3rd party) which is essentially PaX's MPROTECT feature, is actually one of its most useful protections. What's needed is more of that reality-based security, not academic pie-in-the-sky solutions. The former's been working well for years, the latter is still struggling for over a decade to be relevant.

-Brad

Walsh: Introducing the SELinux Sandbox

Posted May 28, 2009 14:57 UTC (Thu) by hppnq (guest, #14462) [Link] (3 responses)

Why's it such a bad idea to make classes of vulnerabilities unexploitable and thus prevent someone from being able to take advantage of an applicable vulnerability for the purpose of arbitrary code execution in the kernel?

It is not a bad idea, although I can't see what you mean by "unexploitable". What I was trying to say is not rocket science, nor is it clouded in riddles.

I never talked about ruling out kernel bugs, you did.

Why on earth do you waste your time on this? Yes, I confess: I did mention ruling out kernel bugs. I invite you to read it again.

Anyway. That Usenix article about automated kernel patching was quite interesting, but also quite silly. Talk about academic pie-in-the-sky solutions. Talk about ruling out kernel bugs.

Walsh: Introducing the SELinux Sandbox

Posted May 28, 2009 16:05 UTC (Thu) by spender (guest, #23067) [Link] (2 responses)

The Usenix article was linked for its quantification of kernel vulnerabilities at any given time, specifically those that are silently fixed or mislabeled by vendors. That's why I specifically quoted that part in my other post; my linking to it doesn't imply my agreement with its conclusions -- I completely disagree with their conclusion/solution.

What don't you understand about "unexploitable"? Understanding that would be pretty important in determining whether the thing I mentioned helps kernel security or not, wouldn't it? You said the example I gave both helps kernel security and is not a bad idea, but neither of those things match up with what you said earlier:
1) "How would patching the kernel help against kernel bugs?"
2) "it seems a bad idea to think that any specific part of the kernel is able to protect the kernel."

So yes, what you're trying to say is clouded in riddles, because it doesn't make any sense whatsoever.

-Brad

Walsh: Introducing the SELinux Sandbox

Posted May 28, 2009 17:58 UTC (Thu) by hppnq (guest, #14462) [Link] (1 responses)

You keep seeing things black and white. So to you, with the right kernel patch (grsecurity, I presume) in place, things become "unexploitable" at one end of the spectrum, while one vulnerablity in SCTP blows away SELinux completely at the other end of the spectrum.

What I am saying is: neither grsecurity nor SELinux will give you the security you claim they do (not) provide, unless you also seriously look at other factors. This is extremely straight forward, the Five Things To Keep In Mind point this out as well. (Your rant and vulnerability disclosure in Thing 2 shines a remarkable light on the Usenix paper indeed.)

I am not sure whether I am really unclear, or whether you really don't understand what I mean, but I think I have said enough about this now.

Walsh: Introducing the SELinux Sandbox

Posted May 29, 2009 19:08 UTC (Fri) by Arach (guest, #58847) [Link]

> You keep seeing things black and white. So to you, with the right kernel
> patch (grsecurity, I presume) in place, things become "unexploitable" at
> one end of the spectrum, while one vulnerablity in SCTP blows away
> SELinux completely at the other end of the spectrum.

Brad was talking about making a *single* class of bugs unexploitable *by design* (with hardware-enforced restrictions of memory management), not about any "things" becoming unexploitable ever.

Walsh: Introducing the SELinux Sandbox

Posted May 27, 2009 15:23 UTC (Wed) by Kit (guest, #55925) [Link] (1 responses)

>You really should refrain from using words like "only" (especially emphasized) when talking about what arbitrary code executing in the context of a large piece of software with many dependencies and addons is limited to doing.
Did you miss where I said 'unless an additional exploit or two are also found in the limited area that the browser can actually access'? Surely limiting the surface area that an exploit could possibly happen is a GOOD thing? And the reason I said 'only' is because in this situation, if the browser is exploited, it can't just immediately copy all your sensitive data to $EVIL_HACKER then wipe your home directory.

>What files of the user the exploit could write to didn't even come into the picture.
Yes it does. The user cares about HIS data when it comes to desktop systems (which this sandbox is an attempt to help protect), and the traditional security model does pretty much NOTHING to protect that on a standard desktop. Not all systems are far off remote servers where no one ever logs in locally, they deserve security systems designed for their situations which so far the traditional systems have largely failed at.

Walsh: Introducing the SELinux Sandbox

Posted May 27, 2009 22:26 UTC (Wed) by spender (guest, #23067) [Link]

You're mixing up terminology. You used the word "exploit" which has a very specific meaning, but it seems like you're now wanting to be credited for meaning "vulnerability." When you say "unless an additional exploit or two are also found in the limited area that the browser can actually access" you're saying that there exist exploit binaries on disk which the browser process is allowed by SELinux to access and execute. In which case, I didn't miss anything at all and it's you who doesn't understand the meaning of "arbitrary code execution."

Now, if you *meant* to say that "unless there is an additional vulnerability or two in the code-paths of the kernel that a large and complex binary like a browser can reach," then we'd be in agreement.

-Brad