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
