What does HackerNews think of bubblewrap?
Low-level unprivileged sandboxing tool used by Flatpak and similar projects
[1] https://github.com/google/nsjail [2] https://github.com/containers/bubblewrap
```
$ alias SafeRun="bwrap --ro-bind / / --dev /dev --proc /proc --unshare-all --tmpfs ~ --bind ~/Untrusted ~/Untrusted"
$ SafeRun python3 ~/Untrusted/RandomScript.py
$ SafeRun ~/Untrusted/RandomExecutable
```
This is basically manually invoking what Flatpak does:
https://github.com/containers/bubblewrap
This is also useful for more than just security. E.G., you can test how your app would behave on a fresh install by masking your user configuration files. I personally also have a tool that uses it to basically bundle all dependencies from an entire Linux distribution in order to make highly portable AppImages— Been meaning to post that, will get around to it eventually maybe.
The flags above should hide your user data (`--tmpfs`), disable network access (`--unshare-all`), hide/virtualize devices and OS state (`--dev` and `--proc`), and make the rest of the root filesystem read-only (`--ro-bind`— Including the insecure X11 socket in `/tmp`, which you might want to expose for GUI apps).
Check them against `bwrap --help`; I might have omitted one or two more things you'd need.
To compare and contrast: bubblewrap is lower level, and is great for embedding or using in one-off invocations, whereas firejail is more oriented towards adding a bit of hardening to everyday applications like Firefox via built-in and custom profiles.
For example, you could temporarily override a path doing something like this:
bwrap --bind / / --bind /tmp/myoverride /usr/lib/qt5.15.2/plugins/kf5 -- ...
Bubblewrap is used internally by Flatpak and others.
Also, Docker and Podman know how to restart containers if needed, depending on a policy you set.
If you want something even smaller, take https://github.com/containers/bubblewrap or https://github.com/arachsys/containers and run them under the process monitor of your choice, like runit or s6.
For the purposes of the autorunner, I use approach 1.1.3 (“always write down the pid of every process you start, or otherwise coordinate between A and B”) and leave it to the user to figure out what happens if the child process misbehaves with relation to any processes it starts.
However, I want to point out that approach 1.1.4 (“A should run B inside a container”) is easier to do than one might expect, and I'd like to plug one of my favourite utilities—Bubblewrap[4]. The Bubblewrap documentation says “[y]ou are unlikely to use it directly from the commandline, although that is possible” but I have built some amazing little tools from it.
Try the following invocation:
bwrap --ro-bind / / --proc /proc --unshare-pid ps
As you can see, there's a lot you can do with this tool with significantly lower overhead than using Docker. It has been my goal for some time to extract some of the functionality of Bubblewrap into a Zsh extension to allow accessing these mechanisms with even lower overhead. I think the creation of namespaces is a missing primitive in Linux shells, and being able to quickly construct namespaced environments allows for a style of safe, robust, simple shell scripting. e.g., if you create a mount namespace to run your script, you can actually be looser about parameterising file locations (since the namespace can ensure everything is exactly where you want it to be.)
[1] https://fosstodon.org/@dontusethsicode/110019380909461936
[2] http://eradman.com/entrproject/
Soon we'll do real sandboxing, either ourselves through Docker, wasm, bubblewrap[1], etc, or an existing FaaS (Lambda, Deno Deploy, Cloudflare Workers) or FaaSaaS (Deno Subhosting)
- Flatpak is terrible because it doesn't follow a file system hierarchy that was invented in the 70ies.
- Flatpak is terrible because my early 90ies package manager is the pinnacle of packaging.
- Flatpak is terrible because I only trust my distribution's packages.
- Flatpak is a security nightmare because it doesn't isolate every application now. (Which is not really possible, because applications/toolkits need to be adapted).
- Flatpak is terrible because now my applications cannot open arbitrary files anymore (including ~/.ssh).
Conservatism is what holds the Linux ecosystem back. We have seen this story before with systemd. This is sad, because Red Hat and others are doing fantastic work modernizing Linux (see Flatpak, Fedora Silverblue, etc.).