Bubblewrap – Low-level unprivileged sandboxing tool used by Flatpak | Hacker News Reader

Bubblewrap – Low-level unprivileged sandboxing tool used by Flatpak

github.com

91 pointsTheFreim28 comments

Fwiw, this was mentioned in the NixOS and my descent into insanity submission yesterday, as it's underlying util bwrap, as a possible tool to help the blogger get NixOS running on their campus computers. https://news.ycombinator.com/item?id=36668363

The org maintaining this maintains a bunch of other very high profile containerization/isolations tools: podman container runtime, buildah container builder, skopeo container registry multitool, conmon-rs container monitor, podman desktop gui, youki container runtime, and maintaining the standard reference impl of a bunch of OCI specs (storage, image). There's no higher profile place this work could come from, imo.

> The org maintaining this maintains

(That org being mostly Red Hat)

Or, as we call it now: IBM

It's actually annoying NixOS doesn't offer good default sandboxing. Sandboxing should appeal to the Nix crowd, but somehow it's not been integrated yet. AFAIK, GuixSD is working on sandboxing.

In general, sandboxing is pretty important and an area were Linux distributions are falling behind macOS and mobile.

NixOS supports firejail - https://nixos.wiki/wiki/Firejail

It does, but it is far from seamless / widely used. It is a little bit more than firejail packed for NixOS.

NixOS is a very DIY/build-whatever-you-want system; what more would you want than it being available including the wrapper function to make applications default to running under it? I guess it could be included in the default ISOs if you wanted to showcase it, but given the non-zero friction it adds I'm not sure about the cost/benefit on that.

I know, I maintain quite a few items in NixPkgs. My point is that Linux distributions are not taking sandboxing seriously compared to mobile or macOS, and this is a big security issue.

E.g., if one runs a compromised binary, such as PyTorch [1], sandboxing as implemented by Firejail or bwrap provides defense in depth. You might be running a compromised binary, but it won't be able to read your entire $HOME and steal your data.

I think NixOS is in a great position to offer seamless integration of one sandboxing framework, thanks to the declarative nature of package derivations. But it'd probably need to support just one framework, as it's a pretty foundational component, just like you can't easily switch from systemd to something else.

[1] https://pytorch.org/blog/compromised-nightly-dependency/

"Sandboxing" can mean one of ten different things, and the ideal is completely dependent on the use case. I highly doubt the same solution would work for, say, both system services and GUI apps.

Right now, NixOS has declarative containers (based on systemd-nspawn) and FHS-compatible user environments based on bubblewrap (where you bring your own packages; see the pkgs.steam attrset for example).

What do you want out of sandboxing in NixOS?

IME (compared to other distros I've used), NixOS actually goes in rather heavily on using the sandboxing features available in systemd.

For instance, most of my machines serve ~name/www as https://.../~name/, but this doesn't work out-of-the-box on NixOS, since nginx's sandbox isn't able to read /home by default.

> sandboxing is pretty important and an area were Linux distributions are falling behind macOS

How so? Linux has cgroups, namespaces, containers, and things like Flatpak. And these days rootless containers (where you can set even the allowed syscalls) are good for most use cases too.

In practice, mainstream distributions do not offer ready-to-use zero-conf sandboxing for userland applications.

There are of course exceptions, like those using Flatpak, but what I would like to see is Firejail/bwrap applied to all binaries, with sane defaults.

In other words, if I run python or Firefox and they get compromised, they should not be able to read e.g. ~/.ssh and steal my private keys (unless I gave them permission to).

Nix has done a great work making dependencies declarative and reproducible, I would also like clean sandboxing as it is an equally important issue.

> Firejail/bwrap applied to all binaries, with sane defaults

Isn't that kinda SELinux in the limit?

In 23.05 (the latest release) `buildFHSEnv` was added, which creates an FHS environment inside of a bubblewrap sandbox.

https://nixos.org/manual/nixpkgs/stable/#sec-fhs-environment...

ETA Code (note control over namespaces available for "unshare"): https://github.com/NixOS/nixpkgs/blob/aae1f384fdaecfbeba100c...

I do wonder if some future Nix-variant which based around sandboxing first could make life easier.

Nix seems to have to put lots of work into handling programs that expect to find to find /bin/bash. An alternative would be to put programs in custom sandboxes, where /bin/bash is found exactly where they expect to find it.

I think that still requires lots of work, since lots of programs expect to be able to pass around paths to children/parents and have those paths remain openable.

For instance, if both cmake and ld get their own sandboxes, with their own view of /lib, it seems pretty likely that cmake's -L flags will get mixed up, in a way that's harder to debug than "oh, CMake passed -L/lib/foo; nothing should use /lib, so I need to find where that's hardcoded."

> put programs in custom sandboxes, where /bin/bash is found exactly where they expect to find it

NixOS can do that, I think it was necessary to get Steam games running

https://nixos.org/manual/nixpkgs/stable/#sec-fhs-environment...

> an area were Linux distributions are falling behind macOS and mobile.

Projects that matter in the Linux world have all understood that and are working on it from systemd starting spawnd to Gnome being all-in on Flatpak.

For all the publicity it's getting there, NixOS is really a very niche effort with little man-power.

It was also mentioned recently in Julia Evans’ lima post: https://news.ycombinator.com/item?id=36668964

It's mostly (great) Red Hat containers projects

Wonderful little tool, too bad you must chain various exec calling tools to get cgroups (a bit akin to `ionice ... nice ... cmd`) and Linux users namespaces can't allow UNIX sockets while preventing network access (I think?).

Migrated from Firejail when its complexity annoyed me too much and I hit https://github.com/netblue30/firejail/issues/3001 (Firejail doesn't like parens or brackets in --put/--get parameters) to a badly NIH version using bwrap and bash to have "profiles": https://git.sr.ht/~q3cpma/scripts/tree/master/item/bwrap_aut... https://git.sr.ht/~q3cpma/scripts/tree/master/item/bwrap_eas...

PS: strace is your best friend when trying to make bwrap profiles

Also of interest is https://github.com/igo95862/bubblejail , a less low level program on top of bubblewrap.

Does bubblewrap have network isolation? I have multiple DUT which require their own ip address. I use libvirt-sandbox at the moment but its clunky.

It can create network namespaces but you need to use other tools to actually set them up.

Thanks!

I wish they would merge pull request #547 or one of the other proposed overlayfs options, would make a lot of interesting use cases into (granted, complicated) one liners. As it is now, linux overlayfs is "by wizards, for wizards" type of thing with an amazingly hard to do setup procedure.

Bubblewrap is also the name of Google's pwa to twa tool.

Why pick the same name?

https://github.com/GoogleChromeLabs/bubblewrap

This Bubblewrap is much older than the one you've linked.

Reply on news.ycombinator.com