Support private files in the Nix store

[edolstra]

Sometimes it's desirable to have files in the Nix store that are not world-readable, such as configuration files containing passwords. This could be implemented as follows:

• Private files are marked as such by giving them a certain magic prefix to the name, e.g. p:. When these are registered, Nix should make them readable only to root (permission 0700) and the calling user (using an ACL). (The Nix daemon knows the uid of the caller.)
• The permissions on a derivation should be propagated to the output paths. Also, private derivations should be run with a umask of 0077.
• If another user attempts to register an already valid private file, then its uid should be added to the ACL of the file. If it's a derivation, then the uid should also be added to the ACLs of any valid outputs.
• Store operations that read files from the store (such as exportPath()) should check that the caller is in the ACL of the file.

So, for instance, if the root user builds a NixOS configuration containing some private files, then those files are only readable as root. If Alice builds the same configuration, then those files will be readable by root and Alice. If Alice then uses Charon to copy the configuration to a remote machine (i.e. nix-copy-closure --to root@remote ...), then the files on the remote machine will only be readable by root.

This model only allows files that are private to the instantiating user and root. So it doesn't support specifying a file that is readable only to the sshd user. But that's probably not necessary.

[shlevy]

A few questions:

• Does this potentially break nixos-rebuild build as non-root?
• Is there any way to tell as a user that I've attempted to register an already-valid file? For example, if root and I both use the same password file for a particular program, will I be able to tell when I add that file to the store that root has the same one?
• Would there be a reasonable way for a NixOS-managed service to know how to find per-user private files?

[edolstra]

• It shouldn't break non-root nixos-rebuilds since any private files would be owned by (or accessible to) the calling user.
• If a user attempts to register an already-valid file, he would be added to the ACL to the file. So he could conclude from this that root needed the same file.
• What kind of service, and why would it need to do that?

[viric]

What about the build users? Should they be in the ACLs?

[chaoflow]

Being able to tell that somebody else generated the same private file sounds like a no-go for me.

What do you think about including the user the file is private to, i.e. the one who created it, to be included in the hashing (for example an empty file with the user's name in the output)? So even if root, Alice and Charon all want a file with the same content, they would end up with 3 different files.

[shlevy]

The problem with including the user in the hashing is you may eventually share stores, but it's better than nothing. Maybe a wrapper function in nixpkgs that hashed in a GUID read from some personal file? So I have ~/.nixpkgs/guid and when I run pkgs.lib.privateFile 'mypass' "passw0rd" it creates a file whose first line is passw0rd and the second line is the guid?

[edolstra]

Why is this a problem? If the secret stored in the file is sufficiently secure (i.e. random), then this won't happen. I mean, if your login password is "foobar", then other people may be able to find out. So just don't do that.

[shlevy]

Eh, it's not really a problem, at least not for nix itself. The security-paranoid folk can just make sure all of their private files have some unique identifier included.

[mornfall]

Unless I am mistaken, private files in the store are sensitive to offline dictionary attacks, since you can learn the hash and you have a procedure to check your guesses. It is also conceivable, that a rainbow attack could be mounted against a particular version of nixpkgs. It would be advisable that any such private files contain significant salting, regardless of the "learn a secret by random collision" problem. A hypothetical lib.privateFile could then enforce that salting by taking a template string and substituting in the salt (which makes it possible to hide that salt in comments or other such convenient places).

[viric]

Yes, the sysadmin could care storing the salt somewhere only readable by the root user.

[domenkozar]

There is a use case for pkgs.bacula that bacula user needs access to a configuration file with passwords (so non-root).

[MarcWeber]

Alternative quick & dirty solution which may be useful for some use cases: https://github.com/MarcWeber/nix/blob/experimental/write-file-hashed/.topmsg

[domenkozar]

Better link to see @MarcWeber diff: https://github.com/MarcWeber/nix/compare/experimental;write-file-hashed

What's the current workaround for this if a config file includes a password?

[MarcWeber]

My version allows storing passwords in config, but instead of writing it to the store a path to a file containing it will be written to the store. The containing file can be read only by root. The complicated piece is that you have to write code which has to be run as root (eg when preparing config files for services) - but its very easy to review (eg in contrast to patching nix store allowing paths to be readable by some users only requires to think about many issues such as copying store paths - preserving privileges thereby etc). State is "I don't use my patch but it should be working".