[Nix-dev] NixOS issue: Passwords and Nix store

[Nicolas Pierron]

Hi list,

I think most of you are aware of the problem.  The problem is that
the content of the nix store is public.  So if password are part of
derivations or parts of the build result, they would appear in as
readable inside the nix store.

In NixOS, to work around this issue, we have to either pass filenames
with double quotes, to escape from the copy of the file into the nix
store.  This has 2 disadvantages. The first one is that most of the
options do not ensure that you cannot give a path to them.  The second
one is that this prevent us for creating abstractions over the content
of the configuration file in order to ensure consistence of configuration files.

We have multiple solutions to handle this problem.

1/ make private stores and refuse to delegate/share some derivations &
path with stores which are more accessible (only share with more
restrictive ones).

  /nix/store/*-foo.conf.drv --> /nix/per-user-store/*-foo.conf.drv
  /nix/store/*-foo.conf --> /nix/per-user-store/*-foo.conf

  /nix/per-user-store/root/*-foo.conf.drv
  /nix/per-user-store/root/*-foo.conf

such a way, the store can work on the dependencies (registered when
the user has build it's private directory) while keeping a reference
inside the real store.  Such a way, you can have general file indexing
private files.  To read those privates files, you will need to be
compile the data under the most restrictive user.

Please note that the symbolic link is read-only otherwise this would be a
security issue.

With this method, the derivation could inherit the rights of the nix
expression which contains it and a flag can be used to mark derivation
as shared or not.

2/ Provide wrappers and private ""database"" of per-user password collection.

Such a way we can provide a mean to reference password by using their
key to replace them inside the configuration file.  So when using a
file, you will have to reference the static ( /etc ) version of the
file which is build out of the store version of the file.  The store
version would see all the password-keys replaced by the passwords by
the activation script.

{
  options = {
     configFile = mkOption {
       ...
       # Convert configuration file with password keys into a static
       # file with real passwords
       apply = SubstitutePasswords "root";
     };
  };

  config = {
    foo.password = "<@foo.password.key@>";
    configFile = ''
      [dummy]
         user = foo
         password = ${cfg.foo.password}
    '';
    activationScript.activatePasswordFoo = configFile.activationScript;
  };
}

One problem is that such system move the dependencies to the
activation script.  This would mess-up the dependencies.

-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/