containers/bubblewrapLow-level unprivileged sandboxing tool used by Flatpak and similar projects
Many container runtime tools like systemd-nspawn, docker,
etc. focus on providing infrastructure for system administrators and
orchestration tools (e.g. Kubernetes) to run containers.
These tools are not suitable to give to unprivileged users, because it is trivial to turn such access into a fully privileged root shell on the host.
There is a feature in the Linux kernel called user namespaces which allows unprivileged users to use container features. Bubblewrap uses these to build the sandbox, allowing any user to use the tool.
Historically, bubblewrap also supported a setuid mode for systems where unprivileged user namespaces were not supported. However, this has been removed.
The original bubblewrap code existed before user namespaces - it inherits code from xdg-app helper which in turn distantly derives from linux-user-chroot.
The maintainers of this tool believe that it does not, even when used in combination with typical software installed on that distribution, allow privilege escalation. It may increase the ability of a logged in user to perform denial of service attacks, however.
In particular, bubblewrap uses PR_SET_NO_NEW_PRIVS to turn off
setuid binaries, which is the traditional way to get out of things
like chroots.
bubblewrap is a tool for constructing sandbox environments. bubblewrap is not a complete, ready-made sandbox with a specific security policy.
Some of bubblewrap's use-cases want a security boundary between the sandbox and the real system; other use-cases want the ability to change the layout of the filesystem for processes inside the sandbox, but do not aim to be a security boundary. As a result, the level of protection between the sandboxed processes and the host system is entirely determined by the arguments passed to bubblewrap.
Whatever program constructs the command-line arguments for bubblewrap (often a larger framework like Flatpak, libgnome-desktop, sandwine or an ad-hoc script) is responsible for defining its own security model, and choosing appropriate bubblewrap command-line arguments to implement that security model.
Some aspects of sandbox security that require particular care are described in the Limitations section below.
This program can be shared by all container tools which perform non-root operation, such as:
We would also like to see this be available in Kubernetes/OpenShift clusters. Having the ability for unprivileged users to use container features would make it significantly easier to do interactive debugging scenarios and the like.
bubblewrap is available in the package repositories of the most Linux distributions and can be installed from there.
If you need to build bubblewrap from source, you can do this with meson:
meson _builddir
meson compile -C _builddir
meson test -C _builddir
meson install -C _builddir
bubblewrap works by creating a new, completely empty, mount namespace where the root is on a tmpfs that is invisible from the host, and will be automatically cleaned up when the last process exits. You can then use commandline options to construct the root filesystem and process environment and command to run in the namespace.
There's a larger demo script in the
source code, but here's a trimmed down version which runs
a new shell reusing the host's /usr.
bwrap \
--ro-bind /usr /usr \
--symlink usr/lib64 /lib64 \
--proc /proc \
--dev /dev \
--unshare-pid \
--new-session \
bash
This is an incomplete example, but useful for purposes of
illustration. More often, rather than creating a container using the
host's filesystem tree, you want to target a chroot. There, rather
than creating the symlink lib64 -> usr/lib64 in the tmpfs, you might
have already created it in the target rootfs.
The goal of bubblewrap is to run an application in a sandbox, where it has restricted access to parts of the operating system or user data such as the home directory.
bubblewrap always creates a new mount namespace, and the user can specify
exactly what parts of the filesystem should be visible in the sandbox.
Any such directories you specify mounted nodev by default, and can be made readonly.
Additionally you can use these kernel features:
User namespaces (CLONE_NEWUSER): This hides all but the current uid and gid from the sandbox. You can also change what the value of uid/gid should be in the sandbox.
IPC namespaces (CLONE_NEWIPC): The sandbox will get its own copy of all the different forms of IPCs, like SysV shared memory and semaphores.
PID namespaces (CLONE_NEWPID): The sandbox will not see any processes outside the sandbox. Additionally, bubblewrap will run a trivial pid1 inside your container to handle the requirements of reaping children in the sandbox. This avoids what is known now as the Docker pid 1 problem.
Network namespaces (CLONE_NEWNET): The sandbox will not see the network. Instead it will have its own network namespace with only a loopback device.
UTS namespace (CLONE_NEWUTS): The sandbox will have its own hostname.
Seccomp filters: You can pass in seccomp filters that limit which syscalls can be done in the sandbox. For more information, see Seccomp.
As noted in the Sandbox security section above, the level of protection between the sandboxed processes and the host system is entirely determined by the arguments passed to bubblewrap. Some aspects that require special care are noted here.
If you are not filtering out TIOCSTI commands using seccomp filters,
argument --new-session is needed to protect against out-of-sandbox
command execution
(see CVE-2017-5226).
Everything mounted into the sandbox can potentially be used to escalate privileges. For example, if you bind a D-Bus socket into the sandbox, it can be used to execute commands via systemd. You can use xdg-dbus-proxy to filter D-Bus communication.
Some applications deploy their own sandboxing mechanisms, and these can be restricted by the constraints imposed by bubblewrap's sandboxing. For example, some web browsers which configure their child proccesses via seccomp to not have access to the filesystem. If you limit the syscalls and don't allow the seccomp syscall, a browser cannot apply these restrictions. Similarly, if these rules were compiled into a file that is not available in the sandbox, the browser cannot load these rules from this file and cannot apply these restrictions.
Firejail is similar to Flatpak before bubblewrap was split out in that it combines a setuid tool with a lot of desktop-specific sandboxing features. For example, Firejail knows about Pulseaudio, whereas bubblewrap does not.