Sandboxing for the unprivileged with bubblewrap

Please consider subscribing to LWN

Subscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net.

Sandboxing a Linux application is a task often associated with server-side containers that are exposed to the Internet at large. One wants a database server or web application to be contained, for instance, so that if something goes awry, that does not harm the entire host operating system. But work progresses on sandboxing desktop applications, too. On that front, Alex Larsson and others from the GNOME community have recently started working on a new "user-level" sandboxing utility called bubblewrap. The tool can be used by unprivileged users to run an application in a sandboxed environment, so that it cannot access OS resources and is similarly restricted from accessing the user's home directory.

Much of the effort (or, at least, the highly publicized effort) that has gone into application-level sandboxing in recent years has been driven by the needs of those deploying containers at large scale—in particular, by projects like Docker and Kubernetes that are most popular for web applications. But the desire to isolate a process from the surrounding OS is also relevant to people running desktop Linux distributions.

Ubuntu's snap system and GNOME's xdg-app both incorporate measures to isolate an application process (via mechanisms like control groups and namespaces). But both of those frameworks provide quite a bit more than the sandbox itself. For instance, they define runtime environments that the sandboxed process can depend on for system services and they provide a way to package an application with its dependencies included.

Furthermore, as Larsson explained in an April 29 blog post, container-management tools themselves are generally designed for system administrators and, thus, run as a privileged user. That makes such tools a potential cause for security concern, as granting users access to them means trusting those users with considerable administrative privileges (and, in the case of security bugs, can lead to privilege escalations). In addition, there are several scenarios beyond container orchestration in which sandboxing a process is a wise idea. Development builds of software could be sandboxed to isolate them from the OS, for example, or a sandbox could be used to limit an application's privileges in some specific manner. In short, a sandboxing utility that unprivileged users could employ to isolate a process would find numerous uses.

In response to all of these issues, Larsson and the other xdg-app developers started the bubblewrap project in February. Bubblewrap's internals originated in Colin Walters's linux-user-chroot, which was then ported into xdg-app as a helper application. But the helper was tied in directly to xdg-app in several places. It assumed, for instance, that the sandboxed process would be mounted on top of an xdg-app runtime. The standalone version is more generic, and builds substantially over what linux-user-chroot was capable of.

The bubblewrap README notes that user namespaces could also be used to let unprivileged users do application sandboxing by allowing those users to run an existing container-management tool in their own user namespace. But it points to the ongoing concerns about the security of user namespaces as a rationale for the new project.

As is, bubblewrap provides only a subset of the functionality that user namespaces could allow. In particular, it does not provide control over iptables, which the README says could prevent vulnerabilities like CVE-2016-3135.

Bubblewrap works by creating an empty mount namespace with the root on a temporary filesystem that will be destroyed after the sandboxed process exits. Using switches, the user can construct the desired filesystem environment within the mount namespace by bind-mounting the desired directories from the host system.

On the simple end of the spectrum,

 bwrap --bind /some/chroot / foo.sh

will essentially create a traditional chroot jail. The final argument (here, ) is simply the executable to be started in the sandbox. But the configuration supported by bubblewrap can be substantially more complex. So, for instance, the example shown in the README:

 bwrap --ro-bind /usr /usr \
 --dir /tmp \
 --proc /proc \
 --dev /dev \
 --ro-bind /etc/resolv.conf /etc/resolv.conf \
 --symlink usr/lib /lib \
 --symlink usr/lib64 /lib64 \
 --symlink usr/bin /bin \
 --symlink usr/sbin /sbin \
 --chdir / \
 --unshare-pid \
 --unshare-net \
 --dir /run/user/$(id -u) \
 --setenv XDG_RUNTIME_DIR "/run/user/`id -u`" \
 /bin/sh

creates a read-only bind mount from the host system for and for , but creates its own , , and directories by using the switch.

The switch creates a PID namespace in the sandbox and creates a network namespace. The other options currently supported are IPC namespaces, user namespaces (including specifying a custom UID and GID), and UTS namespaces.

Apart from specifying the UID and GID, no options are provided for the namespace switches. The sandbox isolates the executable from the host filesystem, IPC mechanism, and the network. In addition, the switch can be used to load a set of seccomp rules for the sandbox.

Bubblewrap has now replaced the earlier helper application in xdg-app and is available for the rpm-ostree packaging system. The bubblewrap page notes, however, that it could also be useful in existing server-oriented container environments. Whether that idea catches on or not remains to be seen; in the meantime, bubblewrap provides an interesting extension of Linux's sandboxing capabilities into the unprivileged-user space.