[Nix-dev] store & passwords - once again

[Michael Raskin]

>
>--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.

>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?