Simple sandbox

When running programs that risk being hijacked with code execution vulnerabilities, it is highly advised to sandbox/jail them. Sandboxes are virtual containers for computer programs to run in. Sandboxes make programs run more securely by giving them a "playspace" to run in, preventing them from affecting the broader system while still not greatly limiting their utility to the users. There are many sandboxing methods, from creating entire virtual machines to surround dangerous applications, to simple rules preventing a browser from modifying /etc/passwd. This article Article description::describes the oldest, simplest, and very widely used sandboxing method, namely running a program under a special sandbox user.

The above method is often setup by default on linux programs. For example, when installed, the Apache web server creates a new user called "Apache" that it runs under. That way, if compromised, an attacker would not gain root permissions on the device; only the same privileges that the "Apache" user was granted.

This sandboxing method relies solely on the Unix user and group permissions. It requires no kernel tweaking and little extra software ( and ). It is also possible to avoid and use, but then a password is required each time a sandboxed program is executed.

At a minimum, this or another form of sandboxing should be used for software which:


 * Has a known security/privacy issue.
 * Has a history of security/privacy issues.
 * Is distributed in binary form (e.g. many games).
 * Has large codebase and thus attack surface (e.g. Libreoffice).
 * Is no longer maintained.
 * Is very young (brand new project).
 * Is unstable.
 * Accesses the network (email, web, torrent, etc.).

We assume (without loss of generality):


 * is the package we want to sandbox.
 * 'larry' is our own everyday user.
 * 'Mallet' is an attacker.
 * 'ff' is the sandbox user used only to run Firefox.

Sandboxing Firefox is mandatory, as it matches multiple patterns on our list. Like all big graphical browsers, it has a history of vulnerabilities. In recent releases, it is distributed partially in binary form (includes binary Adobe DRM and installs binary Cisco codecs). It also has a 'huge' codebase and accesses the network regularly.

Let's imagine Mallet can exploit a vulnerability in Firefox to access larry's files (emails, SSH keys, Bitcoin wallet, etc.). If larry runs Firefox under the ff user, then Mallet has only access to the resources available to ff, and would need a further exploit of privilege escalation to access larry's data. This obviously assumes tight permissions set on larry's files. This sandboxing method is not the most restrictive; Mallet could still learn a lot about our system, start new processes as ff, use the network, and do anything a low-level user can. But it is also possible to configure the permissions on our system so that Mallet can do very little as ff (such configuration is not explained here).

Create sandbox user
Root creates the 'ff' sandbox user:

If to  is preferred, use  instead of.

Install and configure sudo
Allow larry to run Firefox as user ff, without need for password:

Since we regard ff as a kind of sub-user of larry, it is convenient to allow larry to run any command as ff. This is not necessary for Firefox, but could be useful for packages with many executables:

If you prefer su to sudo, then instead set a password for ff:

Configure X server access control (optional)
This step is only needed if the package is graphical and your X's access control is enabled.

In order to run Firefox as ff, we could of course start a new desktop session as user ff (login using our display manager), but that would be inconvenient. Instead, we would like to work as larry, but open a Firefox window as ff. For that, root installs xhost:

And larry allows ff to connect to larry's X server (to create windows):

larry runs firefox as sandbox user ff
If you prefer su:

If all went well, Firefox is now running in a window on larry's desktop. The window title says 'Mozilla Firefox (as ff)', to indicate that this window is run by ff.

Migrate config files (optional)
ff will have his own home directory, for storing the Firefox profile, i.e. all browsing settings. That's all the files Firefox needs access to. The precise configuration migration manual is very package-dependent and is beyond the scope of this article. However, assuming Firefox is the only Mozilla software larry has used, root can migrate larry's settings:

Adding shortcut icons.
Now larry can create icons or add Firefox to startup applications in his desktop environment. However, sometimes such graphical tools only allow to enter one command to be executed. We can conjoin xhost and sudo into one command by using sh:

Alternatively, john could invoke xhost already when X session starts.

Here's a sample .desktop file, that could be placed at e.g. ~larry/.local/share/applications/firefox.desktop, to add it to your desktop environment's Applications menu (the changes should be applied as soon as you create the file):

[Desktop Entry] Name=Mozilla Firefox (Sandboxed) Comment=Web Browser Exec=sh -c 'xhost si:localuser:ff && sudo -u ff firefox %u' Icon=firefox Terminal=false Type=Application MimeType=text/html;text/xml;application/xhtml+xml;application/vnd.mozilla.xul+xml;text/mml;x-scheme-handler/http;x-scheme-handler/https; Categories=Network;WebBrowser;

Allow larry to access ff's home
We don't want ff to access larry's files, but it is useful for larry to access ff's files:

For instance, when running Firefox as ff, downloaded files can only be saved in or in.

Multiple humans
This method suffices if larry is the only person using this computer. Otherwise, we need to create a separate sandbox user for each real user in order to have separate sandboxed home directories for config files, e.g. ff_larry sandbox user for larry, ff_alice for alice, etc.

Disallow larry to run Firefox without sandbox (optional)
One problem is: larry can forget to run Firefox using sudo, and can run it directly as himself, e.g. by clicking the Firefox icon. For extra security, we tighten permissions of package files, so that only the sandbox user can run Firefox.

Disallow the owning user (root):

Disallow all other users (e.g. larry):

Let us set the group to ff, so ff user (the only one in ff group) can get access:

However, ff should not modify any package files:

Let's have a look at the results:

Great, now only ff can run (but not modify) Firefox.

These permissions would be lost on any package reinstall or upgrade. We create Portage hook that sets them after every installation:

echo 'post_src_install { chmod -R u-x,g-w,o-o ${D} chown -R root:ff ${D} }' > /etc/portage/env/www-client/firefox

Repeat for other packages.
The script below can be used to quickly set up sandbox for any package.


 * 1) !/bin/bash

[ $# -ne 4 ] && echo "Usage: $0 cat/package sandbox_user sandbox_user_home user" && exit 1

pkg=$1 sbuser=$2 home=$3 user=$4

useradd --home=$home --create-home --shell /bin/false --user-group $sbuser chgrp $user $home chmod 770 $home

echo "$user ALL=($sbuser) NOPASSWD: ALL" > /etc/sudoers.d/$sbuser

qlist "$pkg" | xargs chmod u-x,g-w,o-o qlist "$pkg" | xargs chown root:$sbuser

bashrc="/etc/portage/env/$pkg"

mkdir -p $(dirname $bashrc)

echo "post_src_install { chmod -R u-x,g-w,o-o \${D}  chown -R root:$sbuser \${D} }" > $bashrc

This script can be called like:

Configure Firefox to output sound to larry's PulseAudio daemon
Add a Unix socket interface to larry's PulseAudio daemon:

Tell ff's PulseAudio client to connect over this socket:

Restart larry's PulseAudio daemon and Firefox should now be able to output sound.

Further work
todo: when john clicks on links in other programs, can they open in ff's Firefox window?