Walsh: Introducing the SELinux Sandbox

"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