Support for `firejail` like sandboxes?

[s3rj1k]

Describe the feature:

Add support for basic namespace isolation that can protect $HOME folder from modifications and prevent getting "newprivs".

Describe a use case of this feature:

Often I would need to "protect" my home env from the code "Makefiles" so I use some obscure setup with firejail to run sandboxed shell and be "safe-enough" from "accidental" "rm -rf /".

Acceptance criteria:

1. Should hide $HOME recursively from sub-shell, except from CWD
2. Should allow whitelisting of files and folders for RO access
3. Should block potentially harmful syscalls
4. Should provide private-tmp
5. Should allow hiding DBUS system form sub-shell

[ghudgins]

the team is looking into this!

[s3rj1k]

@ghudgins It would be fine to reuse either firejail or bubblewrap, I would expect just the streamlined integration and not the actual rewriting of sandboxes as such, as this is definitely a hard thing to do and to support.

[ghudgins]

+1 from related discourse post https://discourse.flox.dev/t/dependencies-in-the-os-but-not-in-flox/862

[Avi-D-coder]

Support for sandboxing would likely make me switch to flox from plain nix flakes.

Perhaps sandbox-exec could be used on macOS. https://www.karltarvas.com/macos-app-sandboxing-via-sandbox-exec.html

[ghudgins]

ooo yeah we were discussing internally about macOS being the head scratcher. will check it out.

also came up in discussion is another way to consider solving this--we could show you a warning and/or suggest package installations when a non-nix path is called (we'd have to design a not-annoying-but-useful experience for this but the implementation is something we are familiar with). It's a bit of a different solution from a firejail/isolation approach to this problem.