Is __impureHostDeps still needed if the Apple sandbox support also implements build-chroot-dirs?

@edolstra The idea is that it's not really a global system-wide thing, different derivations will need different accesses. In fact, while I haven't looked through this impl yet to see if @copumpkin has done it already, the plan is to have __impureHostDeps supercede build-chroot-dirs on Linux too, since it's really a property of a derivation, not the system, which files are needed. The idea is that __impureHostDeps will have basically the same syntax as build-chroot-dirs and the darwin impl will bail out when a foo=bar where foo is not the same as bar is specified.

I see that indeed __impureHostDeps is supported on Linux too. @copumpkin Before this is done we should probably update the documentation on that and possibly deprecate build-chroot-dirs

The idea that derivations can bind-mount arbitrary parts of the host filesystem sounds very scary to me, and not something we should have on Linux.

Why? It's a private mount namespace...

For example, you can set

__impureHostDeps = "/root/.config";

and get access to that directory, even if /root is not world-readable.

Ah OK, fair enough. So what can we do about this issue? Perhaps set a set of acceptable parent dirs, like /usr/bin, in the config? There simply is not a good set of paths we can specify system-wide on darwin (and I still stand by my point, that even on Linux this is more a property of a derivation).

Well, on Linux we don't really need it because we have a pure stdenv.

But a set of permissible parent directories sounds good.

Well... Except for /bin/sh, which currently needs a full list of transitive deps but if it were specified in a derivation attr that'd be taken care of by inputDrvs. And except for the cases where some people have (private) build scripts that use /usr/bin/env enough that they've had to add it to their config.

@copumpkin Can you add a setting to limit the parent dirs allowed for the per-drv attr? This will probably mean that stuff in /dev will have to remain hard-coded in the code or config file

That all makes sense. I think we can limit parents on darwin to /System/Library/Frameworks and /usr/lib, since I think those are the only impurities we'll ever need. I'll just make it be a canonicalized prefix of the path, so that if we do need very specific files from elsewhere (only example I can think of for now is dsymutil, which we currently have a no-op shim for but could change that) we can enable them.

I'll make the changes tonight. @edolstra, apart from that, does this seem like a reasonable direction to take things?

Never mind the dsymutil part actually, since there's a purer solution.

Yes, looks good to me.

Great, I'm really excited. I think this will be a key ingredient to accelerate a quality pure darwin stdenv (which is already pretty close to being usable). So far I've been doing all my development with an ad-hoc sandbox wrapped around my calls to nix-build to catch/prevent impurities, but getting this in will speed things up a fair amount and help other developers pick up the pure-darwin work more easily.

@copumpkin FWIW, even with those reasonable defaults I'd like the set of allowable prefixes to be configurable.

@shlevy definitely! I was going to make it another configurable field with a sensible default. Can I ship a different default conf file based on target platform?

@copumpkin You can wrap the default logic (which is in c++, not a default config file) in ifdefery. I'm not sure another way.

Fair enough 😄

Updated again and also fixed a slight bug that let pure-darwin's cmake see too much and thus fail.

I don't think the resulting sandbox profile is the best just yet (or that the code to generate it is the best factored), but I really want to get a MVP for this working so I can get back to the more difficult pure-darwin nixpkgs work. Thus I'm not trying to make this PR as good as it can get, but do plan on revisiting/cleaning up this code once I have pure-darwin in a place where more people can work on it.

Main things I'd like to do better:

• factor the c++ better, and allow nix to abstract over the sandboxing mechanism (so perhaps we can eventually do lxc containerized builds on linux, jails on bsd, and who knows what on windows someday)
• factor the sandbox spec better, to allow the kernel to cache precompiled bytecode of unchanging parts of it across runs, and for us to generate less boilerplatey code

@edolstra actually, I feel a little awkward about keeping "dirs" in the name because neither the configuration key nor the derivation attribute are necessarily directories. In practice, the per-derivation one will usually be individual files, and the configuration one contains one individual file. It seems a little icky to have "/bin/sh" as one of my build-allowed-chroot-dirs, right?

Anyway, I'm not going to bikeshed this too much, since as I said earlier my main goal is to get the basic functionality in (which we can refine before the next big release) so I can accelerate the stdenv development. If you feel strongly about the "dirs" name, I'll put it in for now and move forward.

Also, does anyone other than @edolstra have opinions on this? A quick recap:

• __impureHostDeps: a per-derivation attribute that allows it to specify holes in the sandbox/chroot
• allowed-impure-host-deps: a global configuration setting (non-empty defaults in darwin, empty elsewhere) that specifies which path prefixes are allowed in __impureHostDeps. For example, if your derivation specifies __impureHostDeps = [ "/Users/you/mySecretFile" ] and allowed-impure-host-deps doesn't contain /, /Users/, /Users/you/, or /Users/you/mySecretFile, you will get an error when building your derivation.

Hey, I have an opinion too! 👅

@shlevy you're not @edolstra (as far as I know, at least!), so you were included in that! You hadn't expressed an opinion on the deps-vs-dirs naming question 😄

Oh, I thought you were asking for opinions about the work overall 😀 Yeah, I'm in favor of deps or files over dirs.

(also, my goal is to make "chroot" builds the default on darwin after the pure stdenv gets fully merged)

This patch still has a root information leak, namely, you can determine whether files in inaccessible directories exist. For instance, if /root/bla exists, then building

with import <nixpkgs> { }; runCommand "foo" { __impureHostDeps = "/root/bla"; } "ls -l /root/bla"

will print

error: derivation '/nix/store/8vxyw8jcsc41sflf4b2fwi28z9hik31h-foo.drv' requested impure path ‘/root/bla’, but it was not in allowed-impure-host-deps (‘’): No such file or directory

otherwise it prints

error: getting status of ‘/root/bla’: No such file or directory

Yeah, I'm not seeing it primarily as a security mechanism, but I've also noticed that the types of errors you get aren't what they'd be if you were in a blank system. It's still what Apple itself (and Chrome) uses to wall off their system services, so I expect that apart from the information issues it should still be reasonably secure. I don't think there's anything much we can do about the FS error types, but am open to suggestions!

On Jan 12, 2015, at 08:30, Eelco Dolstra [email protected] wrote:

This patch still has a root information leak, namely, you can determine whether files in inaccessible directories exist. For instance, if /root/bla exists, then building

with import { }; runCommand "foo" { __impureHostDeps = "/root/bla"; } "ls -l /root/bla"
will print

error: getting status of ‘/root/bla’: No such file or directory
otherwise it prints

error: derivation '/nix/store/8vxyw8jcsc41sflf4b2fwi28z9hik31h-foo.drv' requested impure path ‘/root/bla’, but it was not in allowed-impure-host-deps (‘’): No such file or directory
—
Reply to this email directly or view it on GitHub.

Oh, sorry, you're talking about the permitted prefix mechanism! Can people catch those nix-level errors?

On Jan 12, 2015, at 08:30, Eelco Dolstra [email protected] wrote:

This patch still has a root information leak, namely, you can determine whether files in inaccessible directories exist. For instance, if /root/bla exists, then building

with import { }; runCommand "foo" { __impureHostDeps = "/root/bla"; } "ls -l /root/bla"
will print

error: getting status of ‘/root/bla’: No such file or directory
otherwise it prints

error: derivation '/nix/store/8vxyw8jcsc41sflf4b2fwi28z9hik31h-foo.drv' requested impure path ‘/root/bla’, but it was not in allowed-impure-host-deps (‘’): No such file or directory
—
Reply to this email directly or view it on GitHub.

@copumpkin I think the issue @edolstra points to can be fixed simply by checking the prefix before checking if the file exists.

Oh, I thought I was already doing that! Will definitely add that later and
figure out why I thought I had :)

On Monday, January 12, 2015, Shea Levy [email protected] wrote:

@copumpkin https://github.com/copumpkin I think the issue @edolstra
https://github.com/edolstra points to can be fixed simply by checking
the prefix before checking if the file exists.

—
Reply to this email directly or view it on GitHub
#434 (comment).

@shlevy Yes, but you have to ensure that the path does not contain .. elements and other obfuscations. Which is what canonPath does, but it throws an error because it's called with resolveSymlinks. But it probably doesn't need to use resolveSymlinks in the first place.

Ah, so perhaps we should catch the exception from canonPath and print the same error message if canonPath throws or if the prefix isn't matched?

@edolstra can you elaborate on the precise threat you're seeing? That a non-root user can learn things about the root account, when running with the daemon? Is it that ": No such file or directory" part that (I assume?) comes from resolveSymlinks?

I don't have too much of a sense of how the daemon works, so apologies for being dense.

I can easily turn off the resolveSymlinks flag, but am not sure what else is needed.

@copumpkin Yes, that's exactly right. I've just merged this PR with resolveSymlinks disabled. Thanks!

Thank you! How long before nixUnstable becomes a real thing again?

It's pretty easy to make an unstable "release", IMO if we have users using it we should just release it.

Looks like the hydra build nixUnstable usually builds off of is broken.

@copumpkin What am I missing? I have a clean nix 1.9 on OSX 10.10 with CLI tools installed. When I try to install something, the derivation build fails with:

sandbox-exec: /bin/sh: Operation not permitted

My /etc/nix/nix.conf is:

build-use-chroot = true
use-binary-caches = false

@datakurre nix knows how to sandbox things, but the darwin stdenv in nixpkgs is currently still quite impure and not set up to behave properly in the presence of sandboxes. There's a massive effort off in a branch called pure-darwin in my fork that we're considering merging back to master soon. It's not yet finished, but it might actually be better than what we have in master right now.

cc @pikajude

@copumpkin Thanks. I try to continue with pure-darwin copumpkin/nixpkgs#77