• Home
• Source Code
• Archives
• About

Linux:Scalablyl Sandboxing Programs

Sandboxing applications on Linux has been a topic of interest for me for a few years now. Seeing distros like Qubes OS got me thinking about how cool it would be to do this without Docker, especially since much of the time Docker images come prepackaged with a huge set of duplicate files that your system already has, like things in /usr, /lib, etc, to say nothing about adding an additional package manager to a system that already has one. Additionally, with things like flatpak and snaps, sometimes the source of application container immages comes with certain security risks that have in the past been problematic because of differences in security requirements for the distribution platforms (think debian repos vs dockerhub which lets anyone publish anything with any level of security).

Everybody Loves Bubblewrap

Bubblewrap isn't a new project (early 2016), but it doesn't seem to be very well known unfortunately. It is essentially a command line utility that allows you to control user namespaces for a process to run inside, also known as a process sandbox. It's a little like a chroot, but much easier to set up and way more powerful, and you don't need root to use it!

For example, if you wanted to use a bash shell on your system, but you wanted a temporary home directory for the user, you could do something like...

bwrap --ro-bind / / \
  --tmpfs /home \
  --dir /home/user \
  --chdir /home/user \
  --setenv HOME /home/user \
  --setenv USER user \
  /bin/bash

The above command will mount the entire system filesystem from / to / in the sandbox as readonly. Then over the /home directory, it will mount a tmpfs volume, so when the process exits all data will be lost. It then creates a directory at /home/user, changes to that directory, and sets a few environment variables for quality of life. Finally, the program to run inside this sandbox is /bin/bash.

Cool! Unfortunately, it gets much more complicated to sandbox apps once you include things like dbus, fake proc filesystems for process isolation (the above /bin/bash can run ps and see all the running processes because it still has access to the real system /proc), device passthrough, supporting system gtk themes, etc. Things can get really complex when trying to limit a process' access while presenting basic things like video or audio access.

A tasty sandwich, er, sandwrap?

Okay, not a very clever name, I admit. A sandboxing script which uses bubblewrap? I have been sandboxing almost everything on all of my sytems lately and I noticed a number of patterns emerge of common configurations between different types of app sandboxes. As I dedupilcated and wrote a unified wrapper to clean this all up, sandwrap was the result. It solves a few problems I had:

• Creates a baseline level of process isolation and security by default (eg: all filesystem access us readonly unless otherwise overridden, no networking access by default, etc.)

• Standardizes a configuration location for all app sandbox configs (~/.config/sandwrap/)

• Standardizes complex and/or repetitive operations like presenting audio, video, the current directory, etc. (wrapopts.add.audio, wrapopts.add.video, wrapopts.add.curdir, wrapopts.add.glib, etc)

• Standardizes some of the more error prone process isolation tactics, such as fake home directories to hide the username, fake but still accessible from the host system /tmp directories to hide the tmp files of other processes, defaults for no networking (requiring explicit requests for network access), etc.

• Standardizes a way to easily wrap existing processes so one doesn't have to juggle a bunch of shell scripts with different configs, making large scale maintenance tremendously difficult.

If you're interested in trying it out, you can find the source for sandwrap here. I've even included a handy examples directory with some common application configs I use on my own systems.