encrypted root fs

[Russell Coker]

As an experiment I setup a machine with an encrypted root fs.

I have attached the patch for mkinitrd which I used.  It is hard-coded for the 
device names that I use (/dev/V0/fc2enc for the encrypted LVM volume) because 
I couldn't think of a good way of storing this.

For production use this would need a --encrypt-root option or maybe reading 
some sort of /etc/crypttab file and deducing that root encryption is needed.

Also with my patch you need to put "--with=dm-crypt --with=aes" on the 
mkinitrd command-line.

To create the encrypted device you have to run
"cryptsetup -d /etc/root-key create crypto /dev/V0/fc2enc" to create the 
encrypted device and then dd a file system of the same size 
to /dev/mapper/crypto.

Finally I've created a statically linked version of cryptsetup for use in the 
initrd and named it /usr/bin/cryptsetup.static .  I've put the binary on 
http://www.coker.com.au/crypt/ as a temporary measure for anyone who wants to 
play with it.  I'll release my code patches once I get them tidied up a bit.

Currently the statically linked version of cryptsetup is 780K in size.  The 
libdevmapper code drags in libselinux code which makes it overly large.  I 
think that perhaps we need to have a statically linked version of the 
libdevmapper code without SE Linux support for use in the initrd (the SE 
Linux policy is loaded by /sbin/init so there is no possibility of doing any 
useful SE Linux stuff from inside the initrd).

I notice that /bin/lvm in the initrd (/sbin/lvm.static on the root fs) is over 
1M in size and includes SE Linux code that is of no use in the initrd.  Is 
the statically linked version of lvm used for anything other than the initrd?  
If not then we should just build it with no SE Linux support because once 
again it can't do anything productive with SE Linux code in the initrd and it 
just wastes space.

Please let me know what you think of these ideas.  I would like to get some 
feedback before I start filing bugzilla reports.

Finally please don't even think of testing this out on any machine that 
contains important data.  There are lots of ways that this can go wrong and 
lose your data.


The aim of this work is to have a system that boots from removable media and 
uses encryption for all block devices so that if it is stolen no data will be 
lost and so someone who gets temporary access to the hardware will have a 
much more difficult time of trying to crack it.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mkinitrd.diff
Type: text/x-diff
Size: 1092 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040816/d42e7685/attachment.bin>