[Nix-dev] Making Nix use pivot_root in addition to chroot

[Shea Levy]

Daniel Peebles (copumpkin) also has some ongoing work to use darwin sandboxes for pure builds on OS X. Perhaps we should try to generalize the interface for these things?

> On Dec 5, 2014, at 2:45 PM, Luca Bruno <lethalman88 at gmail.com> wrote:
> 
> Not a nix dev, but I think by adding an option to nix.conf to use pivot_root makes the patch unobtrusive and easy to merge.
> 
> On Thu, Dec 4, 2014 at 12:24 PM, Harald van Dijk <harald at gigawatt.nl <mailto:harald at gigawatt.nl>> wrote:
> Hello,
> 
> I've recently been trying to use Nix in a somewhat different way than NixOS, and the builders I've got, it would be useful if they were able to run unshare -r. Unfortunately, while this command is normally available to unprivileged users, it is for security reasons not available to unprivileged users in a chroot environment.
> 
> Reading up on how this works, I've come to understand that as one effect of unshare -r is enabling chroot for unprivileged users, and the chroot capability is well-known as being sufficient to break out of a chroot directory, those security concerns are correct, and it is appropriate for unshare -r to report an error if Nix is configured to use chroot.
> 
> However, if chroot is combined with pivot_root, then the mount namespace root and the process root are the same directory again. Since there is no longer anything nothing to break out of, there is no risk of a user breaking out of anything, and then, unshare -r _does_ work.
> 
> A possible problem with pivot_root could have been that it lets the old root remain available inside the new root, but that is easily prevented by unmounting it afterwards.
> 
> The attached patch (to Nix 1.7) to use pivot_root is mainly a proof-of-concept, I know it is not appropriate in its current form. At the very least, it should properly handle systems that lack a pivot_root syscall, and even on systems that do have it, it might be better to make the use of pivot_root optional (compile-time as well as run-time).
> 
> Nonetheless, in its current form it is already useful for testing, which has shown that it addresses the problem for me that I had hoped for it to address, and that it does not cause problems for NixOS packages, which I do continue to use alongside my own.
> 
> Is there any interest in getting something like this in Nix? I would be perfectly happy to clean this patch up, get it into better shape, but I'd like to avoid doing so if (for whatever reason) it is decided that Nix should not be using this.
> 
> Cheers,
> Harald van Dijk
> 
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl <mailto:nix-dev at lists.science.uu.nl>
> http://lists.science.uu.nl/mailman/listinfo/nix-dev <http://lists.science.uu.nl/mailman/listinfo/nix-dev>
> 
> 
> 
> 
> -- 
> NixOS Linux <http://nixos.org/>_______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20141205/7de65801/attachment-0001.html