Sandboxing apps

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

August 10, 2019 — August 18, 2019

computers are awful
diy
Figure 1

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

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

Also related, application firewalls are build of 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 in practice especially secure, and indeed as GTFOBinaries documents, sandboxes are laughably easy to escape using standard affordances.

Some package app standards, notable Flatpak and Snap, have the facilities for sandboxing, although these are usually perfunctory, AFAICT. The other major packaging standard, AppImage, doesn’t actually sandbox at all per 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 but very 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 ricketty 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 to 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). Essentailly 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.