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.
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.
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.
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."
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.
"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).
> 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.
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?).
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.
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.