Sandboxing apps

Upon letting strangers into your house, just so long as they don’t open the door to that one forbidden room

August 9, 2019 — August 18, 2019

computers are awful
diy
Figure 1

Running apps made by strangers in their own little sandbox environments to mitigate the harm they can do to you or, failing that, at least provide an unwarranted feeling of safety.

Related, but not the same, containerization is more about distributing lightly configured machine services than desktop apps.

Also related, application firewalls are built from some of the same stuff, differing mostly in the emphasis (network resources specifically) and granularity (“don’t talk to this site”).

One sandboxes because it is aspirationally more secure. In practice, actually existing sandbox systems are not especially secure, and indeed as GTFOBinaries documents, sandboxes are laughably easy to escape using standard affordances.

Some package app standards, notably Flatpak and Snap, have facilities for sandboxing, although these are usually perfunctory, AFAICT. The other major packaging standard, AppImage, doesn’t actually sandbox at all by default, but they encourage you to use Firejail to manually sandbox. Which I will obviously never remember to do in practice. On one hand, this is not ideal, having to manually assign permissions to everything. On the other hand, there is little evidence that package maintainers put much thought into the permissions they give sandboxed apps generally, so it is probably not substantially worse than the alternatives.

Not sure how any of this weathers meltdown and spectre and other such ridiculous security flaws in our rickety computing systems, but do be careful.

1 Firejail

archlinux says

Firejail is an easy-to-use SUID sandbox program that reduces the risk of security breaches by restricting the running environment of untrusted applications using Linux namespaces, seccomp-bpf and Linux capabilities.

nachoparker’s intro is comprehensible.

2 Bubblewrap

Abstracted from the app standard Flatpak is bubblewrap.

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.

Rumour is it is more secure than Firejail because it doesn’t support all the many things Firejail does (but this means that e.g. bubblewrap doesn’t support audio). Essentially there is a trade-off in modern architectures, between fun interactive multimedia and doing things securely.

However, AFAICT Flatpak apps do support audio. What is going on?

3 Apparmor

AppArmor, the ACL system preferred by Ubuntu is another way to build sandboxes for apps, in that it controls access to resources for processes. It is probably a good way to do things, but the documentation is not accessible to normal schmucks. The Ubuntu community wiki is as close as it gets to a manual that one can read online AFAICT.