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

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

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.

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.

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.