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

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

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.

to post comments

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.