From: "Michael S. Fischer" <michael at dynamine.net>> > I wanted my worker program (which uses EM) to pass the user''s password > to the Expect script via standard input in order to avoid some > security hazards associated with alternatives such as storing it in a > file or in the environment, either of which may be observed by others > logged into the system the worker runs on. > > However, with the aforementioned "sh -c" trick, the password appears > in the output of ps(1), which is also a security hazard. > > For my project to be successful, I need a secure way of communicating > the password to the Expect script. This means I need either EM to be > able to communicate to the subprocess via standard output and close > the output file descriptor yet still be capable of receiving data from > the subprocess, or find some alternative that is equally secure yet > EM-friendly. > > Any ideas? System V IPC comes to mind, but it''s not Tcl-compatible, > and it''s a pretty baroque workaround. :(Just a quick sanity check... If a mode 600 file isn''t safe from prying eyes on the target system, wouldn''t that seem to imply that untrusted users have the same UID as your "worker program" and "Expect script" ? If untrusted users do have that UID, then isn''t all the RAM of all processes running under that UID also visible to them? (If so, then I''d think sending the password via a pipe between processes wouldn''t be secure, just more obscure.) If untrusted users really don''t have the same UID as your programs, then shouldn''t a mode 600 file be safe? (Assuming is stored in a non-world-writable directory...?) Just wondering, Bill
On Jan 15, 2008 9:58 PM, Bill Kelly <billk at cts.com> wrote:> If a mode 600 file isn''t safe from prying eyes on the target > system, wouldn''t that seem to imply that untrusted users have the > same UID as your "worker program" and "Expect script" ?Yes - even root is untrusted here, since nearly everyone has root access to the system.> If untrusted users do have that UID, then isn''t all the RAM of all > processes running under that UID also visible to them? (If so, > then I''d think sending the password via a pipe between processes > wouldn''t be secure, just more obscure.)Security is rarely black and white; it often comes down to choosing the best of a set of imperfect alternatives. Perhaps a root user might force a core dump of the Expect script while it''s running to obtain the password (it''s stored encrypted in the worker daemon), but doing so would be much more work than reading the environment or ps(1), which can be read by anyone, and would be far less intuitive to the average sysadmin than ''sudo cat /path/to/unencrypted/password/file''.> If untrusted users really don''t have the same UID as your programs, > then shouldn''t a mode 600 file be safe? (Assuming is stored in a > non-world-writable directory...?)Yes, but this forces me to incur filesystem I/O ops I wouldn''t otherwise need. I suppose I could use a tmpfs, however, to mitigate the performance impact. Ugh. Best regards, --Michael
From: "Michael S. Fischer" <michael at dynamine.net>> >> EventMachine::popen(%[sh -c "echo #{data} | #{command} #{args.join} 2>&1"]) > > Sigh. I''m afraid that even this hack is not viable.Well, this is extra kludgy so I suggest it more in fun than in seriousness... But I guess mkfifo would be *slightly* more obscure then a regular file... <grin> EventMachine::popen(%[sh -c "mkfifo --mode=600 foo && #{command} #{args.join} < foo 2>&1"]) File.open("foo", "w") {|io| io.puts "supersecretpassword"} File.unlink("foo") ... At least the password will exist in the pipe for a very short time... :) Regards, Bill
On Jan 15, 2008 10:50 PM, Bill Kelly <billk at cts.com> wrote:> Well, this is extra kludgy so I suggest it more in fun than in > seriousness... But I guess mkfifo would be *slightly* more obscure > then a regular file... <grin> > > EventMachine::popen(%[sh -c "mkfifo --mode=600 foo && #{command} #{args.join} < foo 2>&1"]) > File.open("foo", "w") {|io| io.puts "supersecretpassword"} > File.unlink("foo") > > > ... At least the password will exist in the pipe for a very short > time... :)FIFO writers and nonblocking applications appear to be essentially incompatible. By default, both readers and writers of FIFOs block until they have successfully written to or read data from the other side. On the reader side, you can open a FIFO in nonblocking mode and receive a notification when there is data to be read (just like an ordinary file/socket), so that''s not really a problem. On the writer side, however, you can open a FIFO in nonblocking mode, but an ENXIO error will be returned if data is written but there is no reader connected to the other side. There is no way that I know of to receive an asynchronous notification when it''s safe to write data to the FIFO -- and, even if there were, there could be a race condition, since the reader may disappear before the writer sends the data. Best regards, --Michael