Bubblewrap: Unprivileged sandboxing tool
github.comFor those interested in OCI-compatible runtimes, I'm currently implementing rootless containers for runC[1]. This would allow you to get the same sort of unprivileged sandboxing but with a popular container runtime.
Looks neat, but just like the firejail guys they really need to work on their tutorial/readme/docs/manpage.
Many users including myself who want to play around with it get stuck trying to do basic stuff. My first try was using bwrap (not bubblewrap!) to wrap true provides this not very helpful error.
$ bwrap true
execvp true: No such file or directory
~$ bwrap --ro-bind / / true
--symlink SRC DEST
Create a symlink at DEST with target SRC
bubblewrap=`bwrap --ro-bind / /`
Both projects should want to provide tools to help users accomplish the most common cases in a secure manor such as: access to 1 file, 1 directory, network access. As a user my goal isn't to use firejail it is to accomplish something else so the fact that firejail wants to spit out a bunch on stdout is a really weird design choice.
As a user I would want to do the following:
bwrap --rofile foo.txt -- file
bwrap --rodir foo/ -- ls
bwrap --net -- curlI agree, the tool is (currently) poorly documented. I would have appreciated something like this:
But it's never going to be easy. For example:bwrap --ro-bind / / id bwrap --ro-bind /usr /usr \ --ro-bind /lib64 /lib64 \ id bwrap --ro-bind /usr/bin/ps /usr/bin/ps \ --ro-bind /lib64 /lib64 \ --proc /proc \ ps -x bwrap --ro-bind /usr/bin/ps /usr/bin/ps \ --ro-bind /lib64 /lib64 \ --proc /proc \ --unshare-pid \ ps -x bwrap --ro-bind /usr/bin/echo /usr/bin/echo \ --ro-bind /lib64 /lib64 \ echo "to a file outside the container" > /tmp/a-file bwrap --ro-bind /usr/bin/sh /usr/bin/sh \ --ro-bind /lib64 /lib64 \ --bind /tmp/a-file /tmp/a-file \ sh -c 'echo "editing inside, available outside" > /tmp/a-file'- The above works on my 64bit, combined /usr system, but maybe not yours. The more complicated the example, the more likely differences between systems are to show up.
- You may want to run a program with different privileges in different scenarios, so it is hard to guess what the right thing to do is in the general case.
Both bubblewrap and firejail need to be setuid. People commented on the firejail thread that it has a lot of code to be audited. Bubblewrap addresses that by stripping down to the essentials. It's going to have to compensate for that with great documentation and error messages.
I've been wanting something like this to sandbox build systems like npm, cargo etc so you can be sure your dependency resolution can't exfiltrate your keys.
The term "bubble wrap" looks like it is still trademarked[1], even though it's commonly used as a generic term. Hopefully this flies under Sealed Air's radar. I often wonder how far organizations will go to protect physical brands as the world rapidly digitizes.
[1] https://en.wikipedia.org/wiki/List_of_generic_and_genericize...
When you trademark a term, the trademark is usually scoped to a context (eg industry, product type). So, unrelated trademarks can exist with the same name, scoped to a different context.
See eg, https://www.avvo.com/legal-answers/can-i-trademark-a-similar...
Of course, IANAL
Trademarks on inflated cushioning do not apply to software.
They should take the opportunity to change the project name to bwrap to match the fact that the application is not called bubblewrap, but bwrap.