(That org being mostly Red Hat)
In general, sandboxing is pretty important and an area were Linux distributions are falling behind macOS and mobile.
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/
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?
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.
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.
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.
Isn't that kinda SELinux in the limit?
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...
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.
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 can do that, I think it was necessary to get Steam games running
https://nixos.org/manual/nixpkgs/stable/#sec-fhs-environment...
Projects that matter in the Linux world have all understood that and are working on it from systemd starting spanwd 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.
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.