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

W. Michael Petullo mike at
Wed Dec 15 11:06:45 PST 2004

>> Placing the passphrase in an environment variable is not a safe means
>> either.  Reading a passphrase from stdin is probably best.  Another
>> solution I have seen is providing an environment variable that names a
>> file to read the passphrase from.

> As long as the key is stored in the kernel memory you're screwed. The
> only really safe means to do this is to use external devices (such as a
> smartcards) that you offload the crypto to (e.g. host never sees the
> key). That's how it works in most MPEG2 based digital tv systems and
> set-top boxes.

>>> (NOTE:  1. hald shall only allow console user to do this
>>>         2. requires new features in hald to callout a program
>>>            specified in e.g. the /etc/hal/methods.d/Crypto/Sesame/Setup
>>>            file)

>> How does this /etc/hal/methods.d interface work?  I can't find any
>> documentation about it.  I've found a few mentions of a methods.d
>> directory but no documentation about how it is wired to hald.

> It's not done yet is one answer. It will appear in the 0.5.x series;
> until then you will need invoke your binaries manually or through other
> means.

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.


hal mailing list
hal at

More information about the Hal mailing list