[Nix-dev] store & passwords - once again

[Mathijs Kwik]

On Thu, Jul 26, 2012 at 10:46 AM, Michael Raskin <7c6f434c at mail.ru> wrote:

> >
> >--f46d044787ffa1cd7704c5b76f97
> >Content-Type: text/plain; charset=UTF-8
> >
> >On Thu, Jul 26, 2012 at 9:09 AM, Michael Raskin <7c6f434c at mail.ru> wrote:
> >
> >> >Right now, I need to distribute and sync my "secure files" to multiple
> >> >machines. If I could just store the mysql password in the store,
> >> >gpg encrypted, that would make things a lot easier.
> >> >As files can be encrypted for multiple receivers, I can manage
> >> >permissions through that mechanism and just store everything in 1 place
> >> >(channel).
> >> >
> >> >Then, during activation of a new configuration, when some password is
> >> >needed (like when creating a mysql database), "gpg -d" would give a
> >> >passphrase prompt to the person who has chosen this config.
> >> >To avoid interactivity, a passphrase-less key can be used (granted,
> then
> >> >we're back to the current security-level where gaining root/physical
> >> >access gives you all plain passwords), or gpg-agent.
> >>
> >> So what we want is to make some storage for secrets that is accessible
> >> only to the associated builder (so that the secrets are not stored in
> >> derivations)?
> >>
> >
> >Not sure if this is what I propose.
> >Depends on what you mean by "builder". If you mean the script that builds
> a
> >derivation, then no.
> >I want to store encrypted (safe to be readable by everyone) files in the
> >store and it's up to the "builder" (person who gives the command to
> >activate a config) to make sure he has the decryption key.
>
> To create these encrypted files we would need to have some way to call
> encrypting program.
>
> You could hard-code into Nix a way to call GPG, or hardcode a way to
> pass something to builder process without leaving its content in
> derivation. Maybe the secrets would be cleaned up after succesful
> builds.
>

Why not just encode stuff yourself and store it with your configuration.nix?
I mean you currently have to create the file containing the secret yourself
anyway.
Then builtins.readFile can be used to put the encrypted stuff in store,
probably with some metadata to indicate which key(s) would be needed for
decryption.


>
> >This can be a system-wide key, or more fine-grained (organisational
> units),
> >or even separate per-secret-per-machine keys.
> >Indeed some on-the-fly scheme that really acts per build (derivation) is
> >probably possible, but I don't think any secrets are needed during build,
> >but rather during activation.
>
> Public keys can be specified explicitly, so no problem. Private keys
> would be root-readable-only or require access to root-started gpg-agent.
> All this could be described in expressions.
>
> >I think a in-plain-sight solution using encryption won't require much
> >changes to the way the nix (store) currently works.
>
> I tried to do what you say, but you need to remove derivations in that
> case, or encrypt manually.
>
> >Extending this idea a little bit:
> >We can probably have some key management daemon listening on a socket
> (like
> >gpg-agent/ssh-agent) or network port (for central management). Then just
> >point nixos to this socket through a config setting or env var
> >(NIX_SECRETS_SOCKET) when activating and have it ask for keys there. (the
> >agent will then prompt/log that the key for "mysql-machine3" is being
> >requested)
>
> Are you sure that adding _Nix_ support for key management daemon is
> needed?
>

Nope, I'm pretty sure it's not needed at all. Just a plain gpg agent will
probably work. The only issue I can think of is that nix somehow forces
things to turn off interactivity (not provide a tty, timeouts).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20120726/6ce6e2eb/attachment.html