Re: Entering a passphrase interactively in a runit script
On Fri, 27 May 2016 18:45:09 +0200 Laurent Bercot wrote: > On 27/05/2016 18:29, Steve Litt wrote: > > 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. > > That wouldn't work here: in the client-server model, the client is > proactive (it initiates the connection) and the server is reactive. > Here, you want the "server" to actively ask the user for something! Yes, I was thinking of making it the human's responsibility to remember to run the client. In certain situations, that might be reasonable. SteveT Steve Litt May 2016 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21
Re: Entering a passphrase interactively in a runit script
On 27/05/2016 18:29, Steve Litt wrote: 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. That wouldn't work here: in the client-server model, the client is proactive (it initiates the connection) and the server is reactive. Here, you want the "server" to actively ask the user for something! Sure, you could have a common ancestor script that spawns the daemon, waits for it to listen to the socket, then spawns the interactive program, and the interactive program connects to the socket. That's much more complex than you need. The traditional interface used in those cases is ssh-askpass. If DISPLAY is defined, ssh-askpass pops up a window on the user's DISPLAY, asking for a passphrase, and transmit the answer back to the calling program (via a pipe, I suppose). If DISPLAY is unset, I'm not sure what it does, but logically it should use the current terminal to interact with the user. If there's no current terminal, welp, it can't do anything, so a daemon that wants to use ssh-askpass should make sure it allocates a tty first. -- Laurent
Re: Entering a passphrase interactively in a runit script
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 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
Re: Entering a passphrase interactively in a runit script
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