By default, everything in the nix store is readable to everyone. This is most clearly a problem for secrets, but there are other concerns. In container and vm use-cases, it’s very convenient and efficient to share the host’s store, but there are security concerns that this either leaks information about the host, or provides access to tools via store paths that are not intended for the contained system. Even on a single host, there’s often just much more waiting to be found in the store than might be ideal.
I’ve seen a number of methods to address this, particularly for containers and vm’s: explicitly copying the system closure to a dedicated store, various methods with overlays and bind mounts and such to restrict the paths available, and so on. All good ideas worth exploring, with different merits.
But this morning, for 3am reasons, I found a specific and simple thought in my head I just couldn’t get rid of:
What happens if we remove directory read permission for
/nix/store?
i.e. chmod 711 /nix/store, so non-root processes only have search to look up explicit paths
I don’t know! I haven’t tried anything yet. I think there are two main lines of further investigation:
-
What breaks if processes can’t list store contents?
- Normal stuff should be unaffected, because it has explicit links into the store and those paths can still be looked up. By definition everything in the system closure goes via those paths.
- Store manipulation is (or should be) done via the nix daemon, or as root.
- Maybe there are some occasional interactive debugging-style situations where it’s helpful to
ls -d /nix/store/*-somepkg*but those are relatively rare, often have other ways using nix commands, or can be done as root.
-
What actual benefit does this provide / how can it be defeated?
- It’s very much a simple security-by-obscurity measure, and is surely not fully robust, but can it be a help without being trvially defeated such that it’s a false sense of security?
- Some other things would also need to be hidden from containers, that could leak additional paths: the nix store db, previous system generations maybe, what else? Some of these are already not included.
- Some paths are obviously predictable, common tools from hydra builds for example. But things that represent (for example) vm/container host configuration details should be less so.
Comments? Please help me get rid of this idea if it’s already been killed or covered elsewhere.