Sanboxing

Posted Feb 1, 2010 23:15 UTC (Mon) by cmccabe (guest, #60281)
In reply to: Sanboxing by jamesmrh
Parent article: Security in the 20-teens

The seLinux sandbox looks promising. For some reason, policycoreutils doesn't include the "sandbox" program for me in Fedora Core 11. It must have been added after the distro was released.

Maybe this is a dumb question, but are there any plans to sandbox apps "by default" in the future? Or is the goal to ship SELinux policies that are restrictive enough to contain misbehaving processes running as the local user? One of the points that was advanced in favor of seccomp was that there's no "off switch" like there is for seLinux.

Sanboxing

Posted Feb 2, 2010 0:35 UTC (Tue) by jamesmrh (guest, #31622) [Link] (1 responses)

It's a Fedora 12 feature.

I think it'd be useful to transparently sandbox some applications, and then perhaps break the sandbox if the user initiates an action which requires access outside.

e.g. all pdf viewing is sandboxed by default, but if the user wants to save the file, the sandbox is disabled for that access (need to ensure that the user clicked save w/ trusted path). Complex apps like firefox are more difficult, but not impossible.

One of the points that was advanced in favor of seccomp was that there's no "off switch" like there is for seLinux

Disabling SELinux can be prevented (modulo kernel bugs).

Sanboxing

Posted Feb 2, 2010 10:02 UTC (Tue) by nix (subscriber, #2304) [Link]

But about half the security holes on a Linux system *are* kernel bugs, and they're particularly nasty to fix because they require a reboot (which almost no other security fix does). So all an attacker waiting to own a system has to do is wait until a vulnerability window opens but you haven't rebooted, and then attack. Brad Spengler has demonstrated just how fast an exploit can be whipped up in that situation by someone with sufficient skill (and I'm quite certain major governments employ a good few such people).

Sanboxing

Posted Feb 2, 2010 16:10 UTC (Tue) by mjthayer (guest, #39183) [Link] (1 responses)

A dumb follow-up question, but one that has been on my mind for a while: are there any (more or
less) simple ways a *user* process can drop its privileges and enter a sandbox voluntarily without
using something as heavy duty as SELinux? Like setting the RLIMIT_NOFILE hard limit to one after it
has opened all files and sockets it needs? I am assuming of course that it is a true user process,
not setuid root or whatever.

Sanboxing

Posted Feb 2, 2010 18:52 UTC (Tue) by drag (guest, #31333) [Link]

Use LXC.

I can setup a LXC container as root that then can be safely used by users.
This is done through Linux file capabilities and does not require any
setuid programs or anything to be done.

It's as simple as running 'debootstrap' in a directory, installing firefox
into it, and then setting up a lxc configuration.

From then on users can execute firefox from that environment, using their
own UIDs and such, and have the output passed to Xephyr or to their own X
server.

I've done it. It works, it is fast, and unlike chroot it does not require
root rights and is designed for security. It has various levels of
isolation you can setup.

Unlike SELinux it's easy to understand and for mortals to understand.