Not logged in
Log in now
Create an account
Subscribe to LWN
Pencil, Pencil, and Pencil
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
Little things that matter in language design
Walsh: Cool things with SELinux... Introducing sandbox -X
Posted Sep 18, 2009 9:56 UTC (Fri) by PaXTeam (subscriber, #24616)
the author did, here's the relevant excerpt:
This allows administrators to take untrusted content, run it through one or more filters, and be able to trust that the content can't cause the filter programs to do evil things.
Posted Sep 18, 2009 11:36 UTC (Fri) by rahulsundaram (subscriber, #21946)
Posted Sep 18, 2009 12:09 UTC (Fri) by PaXTeam (subscriber, #24616)
Posted Sep 18, 2009 12:58 UTC (Fri) by rahulsundaram (subscriber, #21946)
Posted Sep 18, 2009 13:28 UTC (Fri) by PaXTeam (subscriber, #24616)
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.
Posted Sep 18, 2009 13:55 UTC (Fri) by rahulsundaram (subscriber, #21946)
Posted Sep 18, 2009 14:06 UTC (Fri) by PaXTeam (subscriber, #24616)
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.
Posted Sep 18, 2009 14:26 UTC (Fri) by rahulsundaram (subscriber, #21946)
Posted Sep 18, 2009 15:41 UTC (Fri) by nix (subscriber, #2304)
(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.)
Posted Sep 18, 2009 17:01 UTC (Fri) by dlang (✭ supporter ✭, #313)
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.
Posted Sep 20, 2009 19:40 UTC (Sun) by nix (subscriber, #2304)
Posted Sep 18, 2009 12:58 UTC (Fri) by hppnq (guest, #14462)
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.
Posted Sep 18, 2009 13:54 UTC (Fri) by PaXTeam (subscriber, #24616)
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.
Posted Sep 18, 2009 14:44 UTC (Fri) by hppnq (guest, #14462)
That is enlightening.
Posted Sep 18, 2009 15:15 UTC (Fri) by PaXTeam (subscriber, #24616)
Posted Sep 18, 2009 15:02 UTC (Fri) by iq-0 (subscriber, #36655)
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.
Posted Sep 18, 2009 15:26 UTC (Fri) by PaXTeam (subscriber, #24616)
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" :).
Posted Sep 18, 2009 18:58 UTC (Fri) by gmaxwell (subscriber, #30048)
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.
Posted Sep 18, 2009 23:27 UTC (Fri) by PaXTeam (subscriber, #24616)
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?
Posted Sep 20, 2009 8:31 UTC (Sun) by iq-0 (subscriber, #36655)
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds