Re: Entering a passphrase interactively in a runit script

From: Steve Litt <slitt_at_troubleshooters.com>
Date: Fri, 27 May 2016 12:29:35 -0400

Wow!

I didn't understand all of that, but it does point to the fact that
there's no simple answer.

It sounds like you want a human to type in the password. I can think of
two ways to do it, without having the password hanging around on disk
or in history or the environent:

1) Have a human invoke the daemon rather than Runit

2) Have the daemon that needs to receive the password listen on a
   socket, and have a front end program (could be telnet) ask the human
   for the password. This could be expanded to provide other
   communication between the daemon and the human.

If you do #2, I'd like to hear all about it, to the extent that you can
tell given the obviously trade secret nature of what you're doing.
 
SteveT

Steve Litt
May 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21

-- 
SteveT
Steve Litt 
May 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
On Fri, 27 May 2016 10:49:40 +0200
Christophe-Marie Duquesne <chmd_at_chmd.fr> wrote:
> 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 - 16:29:35 UTC