Feature parity with guix shell --container: optional isolation for nix-shell

[vp2177]

Is your feature request related to a problem? Please describe. I would like to use nix-shell/nix shell as a docker run -it -v "$PWD:/a" -w /a replacement, so I can run potentially untrusted code, for example as part of a build process. I'd like to prevent it from

• being able to make persistent modifications to the system, outside the current directory
• being able to read user and system data unnecessarily, etc.

Describe the solution you'd like Something on par with what guix shell --container --pure --network achieves:

• only the current directory is mounted within the shell (*except some strictly necessary ones)
• network access can be granted or denied per shell
• processes within the shell can't see processes outside
• other isolation that containers usually provide

Describe alternatives you've considered Using a container engine (docker, podman), or virtualization solution (lxc, Vagrant). While these are widespread and work well, it would be nice to get the granularity and wide selection of nixpkgs, as opposed to less granular container/os images. And also, being able to share /nix/store would save disk space.

:heavy_plus_sign: Plus, this would make Nix a "Docker-killer" for the development environment use case.

Additional context https://guix.gnu.org/manual/en/html_node/Invoking-guix-shell.html

[SuperSandro2000]

I would like to run potentially untrusted code, for example as part of a build process. I'd like to prevent it from

• being able to make persistent modifications to the system, outside the current directory
• being able to read user and system data unnecessarily

Containers do not provide enough isolation to run completely untrusted code. That's why most CIs are also run inside a VM and containers are only used to provide and potentially extend the CI environment.

---

Doesn't the nix sandbox already provide most of this?

[RaitoBezarius]

It does not seem like this is using any container engine, more kernel namespaces features better exposed through the CLI.

[vp2177]

@SuperSandro2000

Doesn't the nix sandbox already provide most of this?

Perhaps, I am new to nix.. How do I run a shell in a sandbox (with nix-shell)?

Containers do not provide enough isolation to run completely untrusted code. That's why most CIs are also run inside a VM and containers are only used to provide and potentially extend the CI environment.

One example of what I'd really want to be able to prevent is code running inside a nix-shell being able to read from ~/Documents or ~/.config (think browser cookies or history, for example).

(As for container isolation, maybe this is a bit off-topic, but what harm can malicious code do, when running in a container? - let's assume the container runtime and kernel are up to date)

[RaitoBezarius]

(As for container isolation, maybe this is a bit off-topic, but what harm can malicious code do, when running in a container? - let's assume the container runtime and kernel are up to date)

I will let you look at the history of privesc and security vulnerabilities related to containers, i.e. kernel namespaces features in general and more precisely unprivileged user namespaces which were a nice vector for security vulnerabilities in general.

[vp2177]

@RaitoBezarius I don't think the argument that the Linux kernel had privilege escalation vulnerabilities in the past - like most other software, and will in the future - means that nix-shell shouldn't rely on the features it exposes that are meant to reduce attack surfaces that are available. Of course nothing is perfect. But what I am saying is that it would be nice if nix-shell (or a new command) offered similar levels of isolation to guix shell --container (or to nix-build)

[ribosomerocker]

https://github.com/NixOS/nix/issues/2154#issuecomment-388753582 https://github.com/NixOS/nix/pull/2909 Nix applications were planned to have options for sandboxing, though they were never brought up since then. The sandboxing part, I mean.

There's also a project which tries to make this convenient (do note it depends on bwrap): https://github.com/nixpak/nixpak

[ribosomerocker]

Doesn't the nix sandbox already provide most of this? @SuperSandro2000

It doesn't. The difference is that the nix sandbox is a compile time sandbox, while what people want here is a runtime one, similar to bwrap.