> I am working on implementing encrypted root filesystem support to
> mkinitrd. See
>
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124789 for more
> information and an patch.
I looked at the patch any I see the problem that you need to call
mkinitrd with certain arguments in order for this to work. This
should just kind of determine the parameters (i.e. read them from a
config file written while creating the encrypted root device) used on
the current root fs and apply them automatically so that calls to
mkinitrd from e.g. the kernel pkgs' %post scripts work.
Okay, that's a great point. Where should the configuration file be? /
etc/sysconfig/rootfs would get my vote. I'll code my mkinitrd patch to
a pseudo-standard if we can come to an agreement on the configuration
file path. The file itself should contain something like this:
AUTHTYPE=[none|filesystem|passphrase|rawdevice|paranoid]
KEYDEV=<device holding key>
KEYPATH=<path to key, relative to KEYDEV>
KEYMAT_FSTYPE=[vfat,...]
ROOT_CIPHER=[aes,...]
I imagine we should also write mkfs- and fsck-like tools too (though
this is all more upstream, mount-related work). As mentioned, mkfs
should write a filesystems configuration to (for example) /etc/
sysconfig/rootfs so that mkinitrd may read it.
> This can be implemented pretty nicely using pam_mount
> (
http://www.flyn.org/projects/pam_mount/index.html) because
> pam_mount can unlock filesystems at login time using a user's system
> authentication token. An article I wrote for the Linux Journal on
> the subject of encrypted home directories is available at
>
http://www.flyn.org/docs/ehd.pdf. Note that there have been some
> changes to pam_mount since the article's publication
> last year.
I was thinking of a slightly different thing, i.e. you only mount
the
encrypted, potentially sensitive stuff when you need it and you
definitely don't want it to be unlocked for everyone who -- by
whatever means -- knows your login password. So these two cases need
to be treated differently as well, though I like your implementing
support for the key to be on e.g. a USB stick, this would be helpful
for what I described, too.
If my system password is not unknown to others then my encryption
password is probably no good either. I think root has to be trusted in
most cases. I would be interested to hear any arguments that "only
mount[ing] the encrypted, potentially sensitive stuff when you need it"
would be more secure than unmounting encrypted volumes a login time
(assuming a strong system authentication token).
--
Mike