Walsh: Cool things with SELinux... Introducing sandbox -X

Posted Sep 18, 2009 12:58 UTC (Fri) by rahulsundaram (subscriber, #21946)
In reply to: Walsh: Cool things with SELinux... Introducing sandbox -X by PaXTeam
Parent article: Walsh: Cool things with SELinux... Introducing sandbox -X

Yes, I have read article in its full glory and I don't get it. Explain to me
directly. What is your point? That SELinux can't protect you from all the
kernel exploits? Nobody made the claim that it can.

to post comments

Walsh: Cool things with SELinux... Introducing sandbox -X

Posted Sep 18, 2009 13:28 UTC (Fri) by PaXTeam (guest, #24616) [Link] (6 responses)

ok, let's break it down into simple digestible steps:

1. exploiting a kernel vulnerability to gain privileges (root or others) is an 'evil thing'

2. exploiting a PDF reader to execute arbitrary code is also an 'evil thing'

3. exploiting a PDF reader to execute a kernel exploit as the arbitrary code mentioned in step 2 is also an 'evil thing' by implication.

4. SELinux cannot prevent the exploitation of kernel bugs in general.

5. simple modus ponens yields a direct contradiction with the blog author's statement i also quoted.

or in plain english, when the author claimed protection against 'evil things' he did in fact claim protection against exploiting kernel bugs as well and that is a very bold claim to make. also false.

Walsh: Cool things with SELinux... Introducing sandbox -X

Posted Sep 18, 2009 13:55 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (5 responses)

Wow. So you want every blog post to include a long disclaimer? It should be
obvious to anyone reading it without a very elaborate attempt to find flaws
to know what the author is talking about. Your refusal to engage the author
directly but instead do this on every LWN article on Linux security is
interesting. Feel free to continue. I am sure you are educating a few people
along the way.

Walsh: Cool things with SELinux... Introducing sandbox -X

Posted Sep 18, 2009 14:06 UTC (Fri) by PaXTeam (guest, #24616) [Link] (4 responses)

> It should be obvious to anyone reading it without a very elaborate attempt to find flaws to know what the author is talking about.

it apparently wasn't obvious to you. i'm not even sure it was obvious to the author else one would have to accuse him with intentionally misleading his readers which i'm fairly sure he didn't intend to.

as a sidenote, there was no elaborate attempt needed to find said bug, unless you consider reading kernel changelogs such a challenge (which at times i could even agree with, mind you).

> Your refusal to engage the author directly

well, i tried but got this: this user has disabled anonymous posting.

i somehow don't feel like subscribing to yet another blog when Dan Walsh reads LWN already and LWN has a tiny bit bigger readership anyway.

> I am sure you are educating a few people along the way.

i certainly hope so. for example, you learned the other day the difference between bugs and exploits. now you learned that MAC systems were never meant to prevent 'evil things'. there's a lot more to learn of course.

Walsh: Cool things with SELinux... Introducing sandbox -X

Posted Sep 18, 2009 14:26 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (3 responses)

You haven't managed to educate me about SELinux or security but you sure
have educated others about you a bit more.

Walsh: Cool things with SELinux... Introducing sandbox -X

Posted Sep 18, 2009 15:41 UTC (Fri) by nix (subscriber, #2304) [Link] (2 responses)

It may be the case that PaXTeam's native language is not English. It would be obvious to all native English speakers that 'be able to trust that the content can't cause the filter programs to do evil things' is not the same thing as 'be able to trust that the content can't cause the filter programs to do any evil things whatsoever, forever, regardless of kernel bugs, cosmic rays, and Doctor Impossible', but perhaps it isn't obvious to a non-native speaker.

(More precisely, SELinux is sandboxing the *applications* so that bugs in the *applications* do not cause privilege escalation. It can't sandbox the kernel itself, and never has been able to: the most it can do is 'accidentally' prevent the occasional escalation if, say, some escalation depends on doing something to some entity that SELinux is in any case denying access to. I don't see how anything short of VMs could sandbox the kernel itself, and even then you're vulnerable to kernel bugs in the VM, as PaXTeam et al have said ad nauseam.)

(Perhaps Dan *could* have said as much, but I agree, it is ridiculous to expect every single blog post to come with a long disclaimer lest anonymous trolls rip it to shreds after misreading it. Every security solution has a vast list of conditions it doesn't handle: the place to document that is in the docs for the security solution itself, not in every blog post that ever mentions said security solution.)

(I fully expect to get a bunch of virulently offensive followups to this from the pax and grsecurity trolls, as usual. I don't care, they're irredeemable. It's other people who matter.)

Walsh: Cool things with SELinux... Introducing sandbox -X

Posted Sep 18, 2009 17:01 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

the problem is that the SELinux proponents keep claiming that if everyone just used SELinux there would be no possibility of security problems in linux. and further, because people refuse to use SELinux, all security exploits are then the result of this decision.

that may be overstating this slightly, but not by much.

usually I consider the posts by PaXTeam to be extreme in their claims, but in this case I think the point that is being made that SELinux does not defend against malware in content is absolutly correct.

Walsh: Cool things with SELinux... Introducing sandbox -X

Posted Sep 20, 2009 19:40 UTC (Sun) by nix (subscriber, #2304) [Link]

Oh, I certainly agree with *that*. A lot of SELinux proponents seriously
overegg the pudding. It'll protect only against *userspace* vulns
compromising the local system further: not necessarily against userspace
vulns compromising other systems and not against kernel vulns. Still
that's a fairly large proportion of vulns...