Easy Sandboxing on Linux with Bubblewrap

In a world where security is paramount, the need for a safe environment to run tools has become increasingly important. Sandboxing, the practice of containing a program within a restricted environment, helps minimize potential damage while still allowing the tool to function properly. Bartosz Taudul, known for his work on Tracy, demonstrated a method using systemd-nspawn to create a container configuration, install a distro inside, and bind-mount cache and project folders from the host.

However, the author of this report sought to simplify the process to make sandboxing more accessible and reduce friction.

The author's approach focuses on launching a container-like environment, sharing a read-only portion of the host filesystem to enable the execution of host binaries, and granting read-write access to the current working directory. This setup allows the sandbox to keep the filesystem mostly isolated, except for the directory where the sandbox is executed.

A practical example is running a script within a Tracy checkout, where all host binaries are available, and writes are directed to a tmpfs, preventing any impact on the host system. Only changes within the sandboxed folder are reflected on the host, preserving user IDs and other attributes.

Bubblewrap, an unprivileged sandboxing tool used by Flatpak, was chosen to execute the sandbox. The author's script strings together a lengthy bwrap invocation, encompassing various mount listings. To accommodate GUI applications, an XDG_RUNTIME_DIR and Wayland socket must be created. While the script is not particularly complex, adding more directories to be mounted is as simple as appending them to one of the arrays.

It does not necessitate elevated privileges to operate, but users should bear in mind that the directory where the script is executed is mounted read-write alongside the sandbox.

When dealing with potentially hazardous commands, the author opts for creating a temporary copy of the repository to ensure the original files remain unaltered. Additionally, a read-only GitHub personal access token is automatically inserted into the $GH_TOKEN environment variable within the sandbox, enabling commands like 'gh pr list' to function as intended without any write access.

While this script is far from polished and continues to evolve, it offers a generic solution compatible with both Fedora and AerynOS. By addressing several common issues associated with other sandboxing methods, the author aims to share this script as a helpful resource for those seeking a more straightforward and secure sandboxing experience.

One limitation currently faced is the inability to run podman inside the sandbox due to errors encountered during initial testing. It's possible that additional capabilities need to be exposed; however, further investigation is required to identify the root cause. Lastly, it's essential to understand that this sandbox is not designed to provide a foolproof environment for running untrusted code, and any vulnerabilities may have been inadvertently introduced during the development process.