My notes on making encrypted filesystems 'Just Work(tm)'

W. Michael Petullo mike at
Wed Dec 15 14:16:01 PST 2004

>> Okay.  Is the specification for this interface complete yet?  I would
>> want
>> to know if the will be a safe way to transmit a password from hal to
>> methods.d/foo.  Will hal be able to pass data to foo using pipes?  Or
>> will
>> parameters be encapsulated into foo's environment?  I see two possible
>> techniques here, similar to CGI's POST and GET (sensitive information
>> should not be transmitted using GET).  I'm sure there is other
>> possibilities too.

> Well, my current thinking involves just passing the parameters in the
> environment; here's an idea
> We'd have to figure out how to throw exceptions and do return types.
> Does this way of doing it, pose a problem security-wise? Also remember
> that root can intercept all messages on the system message bus (which,
> incidentally, can be good for auditing).

In my work on pam_mount I realized that many UNIXes allow one to view the
environment a process is running in by using the "ps" command.  Because
non-root users can use this technique, passing passphrases using
environment variables is a bad idea.

This is why I propose passing these parameters using pipes.  Instead of
reading its environment, a script could read its parameters from stdin. 
If we don't do something like this I don't know how hald would pass a
passphrase to methods.d/Crypto/Sesame/Setup safely.

An alternative is to set the name of a file in
methods.d/Crypto/Sesame/Setup's environment (ie: PASS_FILE) and write
Setup to read the passphrase out of that file.  Though this is a solution,
it is quite ugly.


hal mailing list
hal at

More information about the Hal mailing list