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

[W. Michael Petullo]

>> 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.

--
Mike

_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal