Note that a sandbox escape is often possible via TIOCSTI (CVE-2017-5226) [0] unless a special flag (--new-session) is used.<p>Bubblewrap is aware of this, yet their documentation gives no indication that this flag is necessary to produce a secure sandbox. In --help, the documentation of --new-session is simply "Create a new terminal session," which severely understates its importance.<p>It's frustrating to have such a useful tool be knowingly easy to misuse.<p>[0]: <a href="https://github.com/containers/bubblewrap/issues/142" rel="nofollow">https://github.com/containers/bubblewrap/issues/142</a>
Still requires SUID. It makes no sense to have to increase privileges in order to be able to decrease privileges. Any process should be able to spawn a child process with strictly lesser privileges, including granular cpu, memory, network, and filesystem (including path and size restrictions) access. It's sad there isn't a simple, standard cross-platform API for doing this.<p>I would be fine having to rewrite my apps to take advantage of some fancy capabilities-based security paradigm, but give me realistic APIs to do so.<p>I'm currently experimenting with shipping apps as QEMU VMs, packaging QEMU and a minimal kernel with the app. It works surprisingly well, even on Windows with full x86 emulation. And with their newish WHPX API (basically kvm for Windows) the future might be really exciting.<p>EDIT: Someone on the Firejail thread says bubblewrap can be compiled non-SUID and that's the common usage these days. I need to look into this more.
Bubblewrap is a surprisingly useful tool for general system administration tasks.<p>Even though the documentation claims that "[y]ou are unlikely to use it directly from the commandline, although that is possible," I use it as a helper tool in this mode very frequently.<p>This can be very useful for debugging since, for example, you can `bwrap --ro-bind / / --tmpfs ~ $SHELL` to get a "clean" shell in which you can isolate yourself from the effect of configuration dotfiles and can even `--ro-bind my-hosts /etc/hosts` to simulate certain system-level state (without requiring a full VM, heavier container, or root access.)<p>Of course, I've also written some simple shell scripts around `bwrap` to make this all a bit simpler (since this quickly reaches `qemu`-levels of argv proliferation.)
"How does it compare to firejail?" you were going to ask: <a href="https://github.com/containers/bubblewrap#related-project-comparison-firejail" rel="nofollow">https://github.com/containers/bubblewrap#related-project-com...</a>.<p>You're welcome.
This looks like a very useful tool especially for isolating old unsupported daemons and not having to write really complex selinux rules especially in places where others are tempted to just set selinux permissive. And not just because I like bubblewrap IRL.<p>I see there are a few usage examples [1] out there. Are there any bigger collections of examples that people have run across?<p>[1] - <a href="https://wiki.archlinux.org/title/Bubblewrap" rel="nofollow">https://wiki.archlinux.org/title/Bubblewrap</a>
some time ago i made a comparison between different jailing tools: <a href="https://ctrlc.hu/~stef/jails.txt" rel="nofollow">https://ctrlc.hu/~stef/jails.txt</a>
Here is something I'd like to have in fedora (or desktop linux in general): A sort of “workspace manager” using bubblewrap for isolating user-defined groups of applications and file hierarchy.<p>I imagine it as some kind of GUI with “boxes”, each defining a “workspace” with specified permissions (access to that and that folder, network, etc), such that the user could easily drag and drop apps into new workspaces.<p>This way, I could have a “banking” workspace just containing, say, firefox, and a “work” workspace with, say, firefox and thunderbird and whatever, etc. The “workspaces” would by default be as unprivileged as possible, with the possibility to give access to folders, or even maybe to use unionfs or similar to combine the views of different workspaces.<p>For ease of use, I could assign a color or icon to each workspace, and the manager would automatically generate desktop files so that I would easily be able to spot “banking firefox” from “work firefox”.<p>I feel like with bubblewrap, this is only a short python GUI away, and would be super helpful to strengthen security on linux, even more so for non-technically inclined, or lazy people.<p>[Edit:] If someone wants to discuss things further and even maybe try and write a “MVP”, I'd be happy to try.
>Also, @cgwalters thinks trying to whitelist file paths is a bad idea given the myriad ways users have to manipulate paths, and the myriad ways in which system administrators may configure a system.<p>So you either get the entire filesystem or no file access? Isn't this a huge dealbreaker for almost everything?
Does anyone know if it's possible to configure bubblewrap to attach to an existing namespace (network namespace in my case)? I'm selfhosting stuff and wanted a diy container runtime but i can't seem to isolate stuff from the system and still retain some linking between some parts (ie doing stuff like what a docker-compose file specifies).
Who is <a href="https://github.com/containers" rel="nofollow">https://github.com/containers</a>? Well, I see the member list and recognize some names as podman developers. But is there any presentation, policy, statutes...?
I really wish bubblewrap had a way to mount filesystems as copy-on-write instead of read-only.<p>Having ways to impose limits on memory would be nice too.