bubblewrap

I don't recommend using Nix inside PRoot unless this is your only option (e.g.: Android, since there are no user namespaces). The reason for that is that Nix is syscall heavy and using it in PRoot will be slow, really slow. As someone said, the wiki [1] has some interesting options. From the options I used nix-user-chroot [2] with great success, and while the tool is unmaintained it should still work. It uses Linux's user namespaces instead of intercepting syscalls, and this makes the performance pretty much identical to native. If you want more control like PRoot offers, I recommend bubblewrap instead [2]. Another option undocumented is to just grab a recent nix binary somewhere and run. It will automatically create the Nix store inside `$HOME/.local/share/nix` (if I am not mistaken) and use user namespaces to mount to it. However the la

You can rip a rootfs from a docker image using skopeo[1] and undocker[2] then you can puppeteer it with bwrap[3]. This works for most linux distributions (they behave well as fakeroot puppets). Package managers from Debian-based distros tend to misbehave in bwrap in my experience. I use this method to obtain software from various distro repositories or when RPM packages are distributed by vendors. [1] <https://github.com/containers/skopeo> [2] <https://git.jakstys.lt/motiejus/undocker> [3] <https://github.com/containers/bubblewrap>

> Not requiring the cooperation of developers to opt-in, for starters. True, meaningful in the general case, and completely irrelevant in this particular case, which started with specifically the question of OpenBSD applying the protection in question to its own base system. I actually agree that being able to externally impose a sandbox is super useful, but self-imposed restrictions are perfectly applicable in this usecase. > You really think pledge and unveil are equivalent to sandboxing? Can you refer to any sandboxing solution or technologies that limit themselves to restricting syscalls and hiding file paths? Unveil is a lot more useful as a component in sandboxing, I'll give you that. I think that pledge and unveil are a type of sandboxing, certainly. And... I'm struggling to think of any sandboxing tech that does anything but limit

By default steam puts everything in ~/.local/share so I don't see why it would need root. These drivers generally try to prevent you from using virtualization for the same reason they want root. The point is that fundamentally they want to live one level above wherever the user is, which means they compromise user ability to secure against them. The game industry isn't exactly known for slow, careful development, so they're kind of the worst group to give root. Even without a VM, multi-user security does work, and Linux has other tools to isolate programs. Steam already runs in a sandbox[0] on NixOS to give it a normal FHS layout and work at all, so it wouldn't be unreasonable to add more isolation. [0] apparently using https://github.com/containers/bubblewrap which can also do things like PID and network isolation.

I have already been using bubblewrap[1] to isolate KeePassXC from the network and more (the only access it has is to its own private directory and a hardened Wayland socket[2]). I wouldn't recommend relying on devs or maintainers to do application isolation work for you. [1] <https://github.com/containers/bubblewrap> [2] <https://git.sr.ht/~whynothugo/way-secure>

Nothing nix specific but you may be interested in https://github.com/containers/bubblewrap

https://github.com/containers/bubblewrap allows specifying volumes for scripts too

I tend to just make and run shell scripts that configure and run bubblewrap[1]. Everything is nicely explicit and allows for a good mental model of what's going to happen when you run it. source "/path/bwrap_helper.sh" FLAGS=( ${FLAGS_ROOTFS_DISTROX_MIN[@]} ${FLAGS_ENV_XDG_GUI[@]} ${FLAGS_PULSE[@]} ${FLAGS_GPU_ACCEL[@]} --new-session --bind /path/jail123 /home/user ) exec bwrap "${FLAGS[@]}" --seccomp 10 10< /path/a_filter.bpf -- /usr/bin/gui_app "$@" [1] <https://github.com/containers/bubblewrap>