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
--- mkinitrd 2004-05-07 11:50:03.000000000 +1000
+++ mkinitrd.crypt 2004-08-16 10:12:29.000000000 +1000
@@ -638,6 +638,10 @@
echo "lvm vgchange -ay" >> $RCFILE
echo "echo Making device nodes" >> $RCFILE
echo "lvm vgmknodes" >> $RCFILE
+ echo "echo Running cryptsetup" >> $RCFILE
+ echo "/bin/cryptsetup -d /root-key create crypto /dev/V0/fc2enc" >> $RCFILE
+ cp /usr/bin/cryptsetup.static $MNTIMAGE/bin/cryptsetup
+ cp /etc/root-key $MNTIMAGE/root-key
fi
else
echo "echo Creating root device" >> $RCFILE
@@ -651,10 +655,11 @@
echo "echo 0x0100 > /proc/sys/kernel/real-root-dev" >> $RCFILE
echo "echo Mounting root filesystem" >> $RCFILE
- echo "mount -o $rootopts --ro -t $rootfs $rootdev /sysroot" >> $RCFILE
+ echo "mount -o $rootopts --ro -t $rootfs /dev/mapper/crypto /sysroot" >> $RCFILE
echo "pivot_root /sysroot /sysroot/initrd" >> $RCFILE
echo "umount /initrd/proc" >> $RCFILE
+ echo "/initrd/bin/cryptsetup -d /initrd/root-key reload crypto /dev/V0/fc2enc" >> $RCFILE
else
echo "umount /proc" >> $RCFILE
fi
