[HN Gopher] Bubblewrap: Unprivileged sandboxing tool for Linux
       ___________________________________________________________________
        
       Bubblewrap: Unprivileged sandboxing tool for Linux
        
       Author : varbhat
       Score  : 103 points
       Date   : 2022-03-27 19:20 UTC (3 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | lvass wrote:
       | >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.
       | 
       | So you either get the entire filesystem or no file access? Isn't
       | this a huge dealbreaker for almost everything?
        
         | iancarroll wrote:
         | I think this is just a comment on Firejail's implementation, as
         | I think Firejail runs as root and thus must enforce its own
         | permission checks.
         | 
         | It seems like bubblewrap uses a mount namespace created by the
         | current user which would allow controlling access without any
         | special checks.
        
           | dj_gitmo wrote:
           | I'm running firejail now and It doesn't look like it runs as
           | root.
        
             | anderspitman wrote:
             | Correct, it is an SUID executable[0], as is bubblewrap.
             | 
             | [0]: https://en.m.wikipedia.org/wiki/Setuid
        
         | emmelaich wrote:
         | Better to use selinux than path whitelisting.
        
       | lapinot wrote:
       | 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).
        
       | akvadrako wrote:
       | This seems to be the best of breed and it basically the same
       | thing used by flatpak.
        
         | makeworld wrote:
         | My understanding is that this is exactly what flatpak uses.
        
       | jamesdutc wrote:
       | Bubblewrap is a surprisingly useful tool for general system
       | administration tasks.
       | 
       | 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.
       | 
       | 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.)
       | 
       | 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.)
        
       | LinuxBender wrote:
       | 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.
       | 
       | I see there are a few usage examples [1] out there. Are there any
       | bigger collections of examples that people have run across?
       | 
       | [1] - https://wiki.archlinux.org/title/Bubblewrap
        
       | anderspitman wrote:
       | 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.
       | 
       | 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.
       | 
       | 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.
       | 
       | 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.
        
         | mwcampbell wrote:
         | I've also been looking into shipping apps as VM images with a
         | minimal kernel. Do you know if WHPX requires the user to have
         | admin rights? On the host side, Windows and Mac ports of crosvm
         | [1] could be useful. crosvm seems to have all the necessary
         | virtio device types, but a greater focus on security than QEMU.
         | 
         | [1]: https://google.github.io/crosvm/
        
       | dang wrote:
       | Related:
       | 
       |  _Bubblewrap: Unprivileged sandboxing tool_ -
       | https://news.ycombinator.com/item?id=12241971 - Aug 2016 (8
       | comments)
        
       | skywal_l wrote:
       | "How does it compare to firejail?" you were going to ask:
       | https://github.com/containers/bubblewrap#related-project-com....
       | 
       | You're welcome.
        
       | mstef wrote:
       | some time ago i made a comparison between different jailing
       | tools: https://ctrlc.hu/~stef/jails.txt
        
       ___________________________________________________________________
       (page generated 2022-03-27 23:00 UTC)