
Bubblewrap: Unprivileged sandboxing tool - groks
https://github.com/projectatomic/bubblewrap
======
cyphar
For 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.

[1]:
[https://github.com/opencontainers/runc/pull/774](https://github.com/opencontainers/runc/pull/774)

------
icefox
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
    

Looking in the webpage I see that this is what I want works

    
    
      ~$ bwrap --ro-bind / / true
    

Is this what I want to do? I am not sure, maybe I want to expose just
/bin/true, but I couldn't figure that out. It may be using --symlink, but the
docs give no hint as to what symlink actually does. Where does it make a
symlink? And when would I use it?

    
    
      --symlink SRC DEST
               Create a symlink at DEST with target SRC
    

Getting the default behavior right is important as is helping the user,
especially for a security tool. bwrap is a tool that wraps other tools so you
would expect that if I did '$bwrap true' than it would create an empty fs,
expose the one binary it is going to try to run and then run it. Otherwise it
is tempting to insert the following alias which may or may not be a bad
security practice.

    
    
      bubblewrap=`bwrap --ro-bind / /`
    

firejail gets this somewhat right where you can do 'firejail --quiet -- true'
and it just works (although the fact that I have to use --quiet and it still
spits out a \n is both sad and embarrassing)

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 -- curl

~~~
groks
I agree, the tool is (currently) poorly documented. I would have appreciated
something like this:

    
    
        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'
    

But it's never going to be easy. For example:

\- 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.

------
zmanian
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.

------
otoburb
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...](https://en.wikipedia.org/wiki/List_of_generic_and_genericized_trademarks#List_of_protected_trademarks_frequently_used_as_generic_terms)

~~~
ashitlerferad
Trademarks on inflated cushioning do not apply to software.

~~~
icefox
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.

