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

[Posted September 17, 2009 by jake]

Red Hat SELinux hacker Dan Walsh has a weblog posting about a new feature added to his SELinux sandbox. sandbox -X essentially combines the sandbox with the idea behind the "xguest" user to create a sandbox for arbitrary desktop applications. It came out of a request to be able to sandbox "acroread": "Acroread and most other desktop applications use multiple communication channels, interacting not just with stdin and stdout, but accessing configuration files, directly or using interprocess calls as with GConf, the X server and other applications, and usually have full run of the user's home directory. A bug in a desktop application can be exploited to attack other processes on the system through any of these channels. Attempting to lock down access to these things usually just causes applications to break, or at least degrades the user experience. In a nutshell, there was no good, general-purpose way to lock down Acroread, or that matter, any other desktop application."

to post comments

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

Posted Sep 17, 2009 15:38 UTC (Thu) by nix (subscriber, #2304) [Link] (7 responses)

Very cool stuff.

As an aside, the lack of resizing Dan complains about could be fixed by using Xnest under xpra as the sandboxed X server. (This probably won't be quite good enough until the keyboard works properly in xpra, which is really a deficiency in Xnest: there's no way to pass it Xkb options that I can see, so if you specify Xkb options in your xorg.conf, they never reach Xnest, so your keyboard is shagged in xpra. I 'fixed' it by changing the Xkb defaults and recompiling Xnest, but that's hardly a practical solution for everyone!)

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

Posted Sep 17, 2009 21:04 UTC (Thu) by martinfick (subscriber, #4455) [Link] (2 responses)

Xnest does not work very well. If I remember correctly, the last time I tried, video playing, such as with flash, does not work in Xnest yet. With time, I suppose (hope) these deficiencies will be fixed.

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

Posted Sep 18, 2009 3:34 UTC (Fri) by njs (subscriber, #40338) [Link] (1 responses)

Perhaps try Xephyr instead of Xnest? (It's not terribly well maintained either, but it does support all the modern extensions.)

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

Posted Sep 18, 2009 3:41 UTC (Fri) by drag (guest, #31333) [Link]

I like Xephyr, but damn does it screw up the keyboard mappings and I have no clue how to fix it.

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

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

Most of my mentions of 'Xnest' there should be 'Xvfb'. Xvfb is a lot less disgusting than Xnest, but still doesn't support xkb option setting :(

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

Posted Sep 18, 2009 22:41 UTC (Fri) by njs (subscriber, #40338) [Link] (1 responses)

Yeah, in principle xpra should be able to reconfigure the keyboard using the Xkb API, but... this involves the Xkb API.

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

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

Really we need to give Xvfb the same xkb-setting command-line parameters
as Xorg itself. I'll do that next time I go near that code (my existing
just-change-the-global-defaults hack is too ugly to live).

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

Posted Sep 25, 2009 19:56 UTC (Fri) by oak (guest, #2786) [Link]

I don't understand why Walsh claims that Xephyr window is not
resizable. "xrandr -s <width>x<height>" resizes it just fine.

As to:
"Maybe the X team will fix this, or provide a rootless X on X server,
which would let us allow sandboxed applications to at least communicate
with each other."

He could run them on the same Xephyr instance. Applications can be
switched for example with keyboard shortcuts or
using "matchbox-remote -next":
http://matchbox-project.org/documentation/manual/wm.html#...

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

Posted Sep 17, 2009 21:05 UTC (Thu) by martinfick (subscriber, #4455) [Link] (8 responses)

The android security model does much of this already and integrates it well. Perhaps we need a similar security model brought to the desktop? It does seem like we are currently really taking advantage of many of the powerful linux capabilities for desktops.

After all, why not have each real user confined to their own linux container where they have root privileges? Constraint the container appropriately so that a real user has no more power on the host system with this root ability than a real user would today. Within each container, a user would run apps (or categories of apps) as different users with different abilities and additional sandboxing mechanisms. This would give real users access to all the root level sysadmin tools to create sandboxes with standard linux tools instead of creating new ones for regular (non sysadmin) users.

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

Posted Sep 17, 2009 23:22 UTC (Thu) by drag (guest, #31333) [Link] (7 responses)

On most desktop machines the user account is the important target, not root. The important stuff is stored in /home, and that is all you need to do stuff like run keyloggers or sniff user's network traffic.

Therefore the biggest deal for security on a desktop is to contain a attacker in case they find a hole in one of your applications.

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

Posted Sep 17, 2009 23:26 UTC (Thu) by drag (guest, #31333) [Link] (6 responses)

I misread what your saying, sorry.

But I suppose a application running restricted in a Selinux is not really that much different then trying to make a a whole new container for each application. Your still going to have to find a way to manage permissions and poke holes in your containment system so that applications and users can interact in meaningful ways.

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

Posted Sep 17, 2009 23:43 UTC (Thu) by martinfick (subscriber, #4455) [Link] (1 responses)

I was suggesting only putting real users in their own containers, not os users, not each application in its own container. Applications would get their own os users inside the real user's container. This way, real users would be root (in their container) and could manage creation/deletion/permission setting of application users using "adduser", "chmod", chown" ... Application users would be appropriately restricted to fs (/home...).

Naturally, a desktop environement that understood this could set up these application users with the appropriate settings for you, much like the way android does. Effectively, you could create an entire new distribution with this sole purpose with a true focus on desktop sandboxing. Sandbox profiles could be used. Default profiles could be created by the distribution and each app would have a suggested profile. Real users would be allowed to create/script their own sandbox profiles and could apply them to any application over ridding the distribution's suggestions.

If the real user needs to interact with other real users on the system, then appropriate bridges should be created, such as: mount a shared directory in both user's containers (a real host sysadmin would have to set these up)...

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

Posted Sep 18, 2009 0:00 UTC (Fri) by martinfick (subscriber, #4455) [Link]

If you step back and think about it, most distributions sandbox servers quite a bit already by giving them their own users, and sometimes by putting them in chroots (and by using various other security mechanisms). Any bridging that needs to be done between server applications that was not anticipated by distributions (and there always is some) can be done because the person managing the servers typically has root privileges. This same ability needs to be extended to desktop users (on a multi-human user system).

But, distributions typically stop at sandboxing servers, why? Because to manage sandboxing you need root priviliges! Distributions do not typically sandbox human-user apps (desktop apps) because most human users do not have the privileges on a machine to create the necessary bridges between their apps if they were sandboxed. Human users really need "root level" control of their own domain to ever make sandboxing of applications manageable; no distribution can anticipate all the bridges between user applications that might need to be created. Thus, the need for a separate container for each human user, to give human users "root" privileges without compromising the host or other human users.

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

Posted Sep 18, 2009 7:49 UTC (Fri) by mjthayer (guest, #39183) [Link] (3 responses)

For the general case of sandboxing applications to make sure they don't do nasty things to your user data, I wonder whether a user equivalent of dropping privileges (in this case for example access to the filesystem) would make the most sense? An application opens the resources it needs when it starts up and then drops the rights to open any new ones (and if necessary it forks off another, simple and specialised, process before dropping privileges to open any new resources for it that it needs to acquire later). If the application is open source, you mainly just have to study the initial code (opening and dropping privileges) for safety, and even if it is closed source, the author could provide a small open source wrapper to do that bit if they want to convince their users that they are "clean".

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

Posted Sep 18, 2009 15:25 UTC (Fri) by martinfick (subscriber, #4455) [Link] (2 responses)

Wouldn't it just be easier any more in line with traditional unix methods to use user and group permissions for this?

My bookmark files should be owned by the bookmark group, my email by the mail group and my financial info by the finance group. No new API needed, if I want an application to be able to read my email, I put the user for that application in the mail group. No fancy language restricted APIs like in android, and no fancy privilege mechanisms needed. Scripts could do it today. This security binding would remain external to programs (and thus user changeable) instead of having to be programed into every app. Maybe the programmer gets it right, maybe not, you should be able to chose and see it easily. Maybe you want to have multiple instances of the same app with different privileges! You could have a secure web browser that runs as a secure user that you only use to access your bank and is the only one you ever let access your bank. This way, it would not be exposed to compromises from other sites. Imagine a uzbl front end which launches an a uzbl browser instance as a separate user for every site it visits! You could then tweak the privileges that your browser has for every site and assign groups to those users.

No new tools required, but certainly new/better/easier to use GUI tools might be developed to make it easier to manage user/groups and permissions. Security might become something that is considered important to be able to manipulate inside applications. Save dialogs might eventually have options to set group ownership and permissions on saved files, options tabs would have settable defaults for various internally saved files (bookmarks, cookies, passwords...) This would be helpful even today in multi-human user systems. This GUI integration does not typically exist and I suspect would be welcomed by many corporate environments?

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

Posted Sep 22, 2009 18:22 UTC (Tue) by salimma (subscriber, #34460) [Link] (1 responses)

Managing with only user/group permission is probably impossible. Your mailbox is in the 'mail' group, say, but clearly the mail reader should be given additional permissions so that it can access the mailbox within your home directory.

At the same time, you want to prevent other users from using *their* mail readers (also in the 'mail' group, no?) from reading your mail.

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

Posted Sep 22, 2009 18:38 UTC (Tue) by martinfick (subscriber, #4455) [Link]

I think that you misunderstood my suggestion that started this thread, on which I was following up...

There would be no other human users in my container in the mail group to have to shield from. Every linux user in the container would be a user owned and managed by one and only one human user, and would be used for the purposes of running applications by the same human user with different privileges.

Servers, such as the real mail server in this case, would be run by an admin in a completely separate container or on the host... likely served up via imap. They would not run in a human user container and have to share linux user-groups with it (but it could be setup that way too, it's just more complicated for the reasons you described).

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

Posted Sep 18, 2009 8:37 UTC (Fri) by PaXTeam (guest, #24616) [Link] (21 responses)

so how would this prevent something like http://www.youtube.com/watch?v=ShoAOdx0K7I and http://www.youtube.com/watch?v=zsSTukox8ZA ?

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

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

Nobody claimed it would.

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

Posted Sep 18, 2009 9:56 UTC (Fri) by PaXTeam (guest, #24616) [Link] (19 responses)

> Nobody claimed it would.

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.

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

Posted Sep 18, 2009 11:36 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (18 responses)

Selective quoting is always helpful. If you are talking to the author, comment in the blog instead.

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

Posted Sep 18, 2009 12:09 UTC (Fri) by PaXTeam (guest, #24616) [Link] (17 responses)

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.

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.