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

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

i was talking to you because you made an obviously false claim, apparently because you haven't bothered to read the original blog post. the quote was for drawing your attention to what directly contradicted your statement, you're still welcome to read the original in its full glory.

to post comments

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

Posted Sep 18, 2009 12:58 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (7 responses)

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.

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

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

Posted Sep 18, 2009 12:58 UTC (Fri) by hppnq (guest, #14462) [Link] (8 responses)

Fair enough to complain about SELinux if you have a relevant point, but after ten or more of these pointless and increasingly unpleasant conversations I think it is safe to say that complaining to the original author would be more productive. If not, you could consider keeping superiorly quiet.

Anyhow. Did you mean to say in your original comment that the exploit works even if performance counters are not enabled? Because that would be more troubling to me than to know that SELinux does not protect against everything out of the box.

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

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

> Fair enough to complain about SELinux if you have a relevant point

when the entire premise of this sandbox is obviously false, i think that's quite a relevant point. unless you don't actually care about security, that is.

> Did you mean to say in your original comment that the exploit works even if performance counters are not enabled?

no, i meant to point out the obvious, see above. the fact that there's a handy (and silently fixed as usual) kernel bug is just icing on the cake.

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

Posted Sep 18, 2009 14:44 UTC (Fri) by hppnq (guest, #14462) [Link] (1 responses)

Oh, you mean you could have picked any 0day that the Linux kernel is vulnerable to, to show that the SELinux sandbox would not prevent against this kind of attack, and that actual security has more to do with solving this problem than considering why one would be running performance counters on a system where untrusted users are lining up to disarm SELinux?

That is enlightening.

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

Posted Sep 18, 2009 15:15 UTC (Fri) by PaXTeam (guest, #24616) [Link]

regarding who will or will not be running with PERF_COUNTERS: your guess is as good as mine about what distros will do once they begin to release .31+ kernels. but given the apparent need for more 'live analysis' everywhere from servers to desktops, i would place my bet on them enabling this feature as well so the majority of linux users will actually have it enabled.

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

Posted Sep 18, 2009 15:02 UTC (Fri) by iq-0 (subscriber, #36655) [Link] (4 responses)

Note necessarily, the author is talking about preventing an application
from doing evil things. What you're talking about is that the application
exploits some weakness in a component outside the sandbox to perform the
evil things for him (or by opening up the containment to let him do it
himself).

I agree that your examples are very harmful and surely need protecting, but
the premise of this sandbox is not that exploitation becomes impossible,
but normal misconduct.
I can write an entirely valid application that does no exploitation
whatsoever but which can really mess up files so that other applications
start misbehaving in new and exciting ways. That is the type of problem
this sandbox deals with: preventing one application from stepping out of
line. Which is also something that fits the sandbox definition.

Both definitions have their place and I see them as additive not one as the
subset of the other.

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

Posted Sep 18, 2009 15:26 UTC (Fri) by PaXTeam (guest, #24616) [Link] (3 responses)

i'm not sure if you followed the past few years for the stream of vulnerabilities in Adobe products, in particular in their PDF reader, but Dan Walsh surely must have as he specifically talked about preventing "untrusted content" from doing damage, and *not* about sandboxing maliciously written applications per se.

in other words, the implicitly stated threat model is about an attacker sending the unsuspecting user a specifically crafted PDF file that upon view would trigger an exploitable bug in the PDF reader and do whatever it wants. and he stated then that this sandbox would prevent that so that admins can "trust that the content can't cause the filter programs to do evil things". now since a kernel exploit is just regular code i don't see how this sandbox prevents it. then this means that this sandbox is trivially breakable and that makes it useless against the implied threat model. or at least i don't think this sandbox involves asking the potential attackers "but do not include kernel exploit payloads in the prepared PDF files, pretty please" :).

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

Posted Sep 18, 2009 18:58 UTC (Fri) by gmaxwell (guest, #30048) [Link] (1 responses)

So... I should use PAX: Because it is completely and totally unexploitable, and even in the face of user error it remains absolutely secure. Unlike this silly sandbox stuff that only provides greatly increased security against a large portion of possible attacks, and not absolute security like PaX. Did I get that right?

Come on Nothing provides complete security. The sandbox will reduce the exposed surface in a couple of ways, and totally shut down attacks without a kernel or sandbox compromising component. It may even insulate against some kernel attacks by not permitting the required syscalls, though protecting against kernel flaws isn't the stated purpose of the sandbox.

If anyone actually here was confused into thinking that this solved all security problems pointing out that it didn't would be helpful... but things like "when the entire premise of this sandbox is obviously false, i think that's quite a relevant point. unless you don't actually care about security, that is." make you sound like someone completely lacking perspective.

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

Posted Sep 18, 2009 23:27 UTC (Fri) by PaXTeam (guest, #24616) [Link]

> Did I get that right?

no you didn't. PaX doesn't protect you against all kernel bugs, only a few specific classes of them. not sure how all this is relevant here though as i wasn't talking about it at all, not to mention that the purpose of PaX is to protect against remote attacks, not local ones.

> The sandbox will reduce the exposed surface in a couple of ways

is it trivially circumventible or not by the assumed attacker? the answer to this question will tell you how useful it is, that's all i wanted to point out. as for lacking perspective, you are free to make your most trusted personal box available to the entire internet and see how fast it gets compromised and your precious secrets leaked. not so keen on doing it? then why are you suggesting guillable users the same?

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

Posted Sep 20, 2009 8:31 UTC (Sun) by iq-0 (subscriber, #36655) [Link]

I didn't read those words as being such bold statements, but that might
just be my built-in mitigation system ;-) But if you read it like that, than
sure, you're perfectly right.
I'm thinking more along the lines of scripts that do more than just what
you're expecting. A lot of unwanted behaviors has nothing to do about
exploitation, but often are a result of e.g. publishers wanting to know
about their readers (and some readers don't want reading some document
to send notifications to publishers).
And, of course, even a basic sandbox limits the amount of immediately
useable exploits.

Anyway, you have a point if you interpret things so strictly, but along those
lines almost no tech article could be written with long disclaimers after
each statement. But a little more attention about stuff it doesn't prevent
might indeed be in order, especially given the security context of the blog
and the products involved.