Musings about on-disk encryption in Fedora Core

[W. Michael Petullo]

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