Sanboxing
Sanboxing
Posted Feb 1, 2010 22:09 UTC (Mon) by jamesmrh (guest, #31622)In reply to: Security in the 20-teens by cmccabe
Parent article: Security in the 20-teens
With the SELinux sandbox, the default rules for any app running inside are essentially to deny all accesses (e.g. no access to the filesystem, except to load shared libraries, no networking etc.), and we then pass an open file descriptor to the sandbox, over which all communication operates.
This means that the calling program assigns all authority to the sandbox via the open fd, and the sandbox has no "ambient" authority. It's quite a powerful abstraction and we can build more around it (e.g. sandbox X runs graphical apps via a nested X server, communicating over an fd).
See:
- http://video.linuxfoundation.org/video/1565
- http://namei.org/presentations/selinux-sandboxing-fossmy2...
These principles can be applied to other distros/security models.
There's an emerging area of research around the concept of removing ambient authority, see:
http://en.wikipedia.org/wiki/Object-capability_model
We're limited somewhat in Linux by the underlying design of the OS, but as above, we can apply some of the principles.
Posted Feb 1, 2010 23:15 UTC (Mon)
by cmccabe (guest, #60281)
[Link] (4 responses)
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.
Posted Feb 2, 2010 0:35 UTC (Tue)
by jamesmrh (guest, #31622)
[Link] (1 responses)
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).
Posted Feb 2, 2010 10:02 UTC (Tue)
by nix (subscriber, #2304)
[Link]
Posted Feb 2, 2010 16:10 UTC (Tue)
by mjthayer (guest, #39183)
[Link] (1 responses)
Posted Feb 2, 2010 18:52 UTC (Tue)
by drag (guest, #31333)
[Link]
I can setup a LXC container as root that then can be safely used by users.
It's as simple as running 'debootstrap' in a directory, installing firefox
From then on users can execute firefox from that environment, using their
I've done it. It works, it is fast, and unlike chroot it does not require
Unlike SELinux it's easy to understand and for mortals to understand.
Sanboxing
It's a Fedora 12 feature.
Sanboxing
Sanboxing
Sanboxing
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
This is done through Linux file capabilities and does not require any
setuid programs or anything to be done.
into it, and then setting up a lxc configuration.
own UIDs and such, and have the output passed to Xephyr or to their own X
server.
root rights and is designed for security. It has various levels of
isolation you can setup.