Hi,
So many answers in this thread! I did not think this would generate so
much interest. It looks like I am going to use a completely different
method, but for the sake of interest in the answers, I am dropping
here a more detailed description of what was initially intended.
What this does: The program runs with a dedicated user with limited
rights. It pulls messages from an input queue system, encrypts them
individually using symetric encryption and a passphrase, and then
forwards them to another output queue system. There are several queues
on the input system, each of these queues gets their individual
passphrase, so I actually simplified when I was saying that I launch
the program with
exec prog # reads PASSPHRASE from the environment
because what I actually do looks more like:
exec chpst -u user env \
$(cat /etc/passphrases.env) \
program
Where /etc/passphrases.env is only readable by root and looks like this:
QUEUE1="mylongrandompassphrase1"
QUEUE2="mylongrandompassphrase2"
So the user running the program can read the passphrases from its
environment, but cannot open the file /etc/passphrases.env. So runit
is taking care of reading the file and "dropping privileges".
Another thing I did not mention is that the input system has some
limitations forcing me to create several instances of the daemon. As a
consequence I have a master daemon that does:
sv start daemon1
sv start daemon2
sv start daemon3
exec tailf /dev/null
Now for extra security, we wanted to modify this so that the
passphrases are not on disk. And yes, that means non interactive
restart in case of a problem. This would protect us against physical
theft of a hard drive.
Funnily enought the plan was already to use pass
(
http://passwordstore.org) to store the passphrases, but one needs to
unlock a gpg key in order to use it. So somehow the problem does not
change and a passphrase needs to be entered when the daemon start.
Ideally, the "master daemon" would ask for the passphrase of the gpg
key, unlock it, use it get the relevant passphrases of the queues from
the pass repository, and then start the slaves and somehow transmit
these passphrases to each of them, and manage them from there.
So here is the problem in full, which I break down to 2 tasks:
- Get a passphrase at startup interactively from a master daemon (to
unlock the gpg key and get the relevant passphrases from pass)
- Transmit environment variables securely to several slaves
But again, I am fairly certain we are going to use a whole different
approach and just not encrypt these queues like this and rather do
something on disk of the receiving system, so don't put too much
thinking in there.
Thank you so much for your insights!
Cheers,
Tof
Received on Fri May 27 2016 - 08:49:40 UTC