Lightweight and portable app utilities for sandboxing, security and observation of untrusted programs.

Running other people's programs is inherently insecure. Rogue dependencies* 🎯 or hacked library code 🏴‍☠️ (et cetera ⚠️) can wreak havoc, including access all your private parts ‼️—think all current user's credentials and more personal bits like:

• ~/.ssh,
• ~/.gnupg,
• ~/.pki/nssdb/,
• ~/.mozilla/firefox/<profile>/key4.db ...

The alternatives are listed by popularity, descending. The recommended solution is listed last.

A simple method is to run untrusted programs as a different user. This way, the untrusted program can't access anything outside its $HOME dir. In reality, most Linux distributions set default umask to 0022, which means that the untrusted program will be able to read files of other users, unless specifically prevented: secret key directories like ~/.gnupg or ~/.ssh set chmod o-rwx, but other common directories may not.

Popular solution: run untrusted software in separate Docker containers:

# Run in a debian-slim container with shared network and bind-mounted current dir
podman run --rm -it -v "$PWD:$PWD" --workdir="$PWD" \
           --net=host debian:stable-slim ./scary-binary

While fairly accessible (containerization comes free when the project spans multiple stacks and already deals in Containerfiles), this solutions is not safe: Docker/podman ecosystem is vast and prone to its own set of risks and supply chain attacks: using others' prebuilt images, downloading images from third-party registries, exposed docker socket, stewardship by a major US for-profit corporation, fast-paced development (even after >10 years 🙄), countless high-impact security vulnerabilities in the last few years alone, monoculture risk etc.

On GNU/Linux, AppArmor, even with apparmor.d applied, doesn't ship profiles for many popular programs, let alone for major execution environments like python3 and npm, and for custom invocation one need go through explicit aa-exec --profile my-custom-env, but writing custom AppArmor profiles is arcane and much less common than simply using containers ...

Firejail is an indie C project that sets up its own sandbox with virtually no dependencies. Red HatIBM has a reasonable position on it (second opinion). Even after 10 years, the development is still very active and fast-moving. It's a matter of trust. Similarly to AppArmor, it requires writing custom profiles.

Intimidated by Canonical's technologies like AppArmor and Snap (app package format), Red Hat needed something to sandbox their own packaged app image format Flatpak. They didn't like the existing Firejail, so they rolled their own Bubblewrap. It's a reasnobaly simple piece of software (5k SLOC of C, some 1000 lines of Shell) that takes many command-line arguments that can be used to adapt the sanbox environment to the needs of almost any program. It has its bugs and issues, but if you trust International Business Machines Inc. (est. 1911), Bubblewrap is a reasonable choice.

On macOS, sandbox-exec utility exists but is considered deprecated, with most fingers pointing towards Apple Containerization®, which has limitations and risks akin to Docker as above.

A collection of portable Shell scripts that can be used to sandbox programs and applications on modern Linuces:

• sandbox-run: run command in a secure OS sandbox. Provides container-like security (execution in separate Linux namespaces; seccomp filtering) using Linux-native commands unshare(1), setpriv(1) and enosys(1), with only some 150 ms of runtime overhead. No dependencies and just a few lines of Shell.
• sandbox-virt: run command in a virtual machine sandbox. Uses QEMU/KVM and libvirt to quickly spin ad-hoc Linux VMs to run your untrusted programs in. Takes under 30 seconds to build a fresh VM and, once cached, only about two seconds to run/resume it. Easily extended / managed with virsh (CLI) or virt-manager (GUI).
• sandbox-venv: secure container virtualenv wrapper. A simple wrapper for Python virtual environments that wraps .venv/bin/python and other binaries inside .venv/bin with sandbox-run.

This namespace is open to contributions. If you'd like to contrib + maintain useful open-source app sandboxing / security / observability scripts for a particular, maybe hitherto non-covered platform, the simple rule is: start with POSIX Shell and continue from there. Get in touch. 👍