Experimental Support for Cryptsetup

Thomas Penteker

Hello together,

as already stated in IRC I have worked on getting CRUX to optionally provide
users to (fully) encrypt their root partition during installation.
(There is a tool to accomplish the same for existing installations but it's
not fully ready for primetime, as it seems. A tutorial for this could be
written later)

The following steps / patches are subject for discussion; I found them to be
the ideal way to solve the whole issue. Points were I was uncertain to solve
are described at the end of this email.

What's the benefit of these changes?

You will get a fully encrypted root partition which will only allow to be
accessed if the propper passphrase is provided on boot time.

Note: you are required to have a separate, unencrypted /boot-partition where
your kernel and initrd (it conaints cryptsetup-util and the script to request
the password and handle the decryption etc.).

move libdevmapper to core (so that lilo gets built with support for libdevmapper)
alternative: introduce opt/lilo-devmapper with libdevmapper as a dependency
cons: somehow hackish (which package may produce /sbin/lilo?)

create new package cryptsetup-initrd (for the creation of the initrd required for fully encrypted disks)
depends on cryptsetup DONE

there are two options at setup-time to enable the disk encryption process:
a) include support for devmapper and dmcrypt + a reasonable choice of crypto
algorithms in the iso's kernel
b) include support for the crypto stuff as a module and add hints for them
in the installation guide (modprobe dm-crypt + modprobe $ALGO should suffice)

why is there no auto-loading of modules during initrd-phase?

GRUB totally untested [yet] (lack of "sympathy"), should work, too

create initrd-generating script for future kernelupdates?
(not needed if features are built-in statically)

REMAINING ISSUES (with my test-iso)

udev takes a HUGE time to settle if /dev (tmpfs) is mounted from the initrd
So I commented out the mount tmpfs and udevadm settle part in /sbin/start_udev
(first is required, second does not help to speed things up, ^C will help instead...)

when has / to be luksClose'd (if at all), to be safe? /etc/rc.shutdown seems
to be an impropper place. I will investigate this as soon as possible

core and opt have to be installed separatly (some function gets called with
four instead of seven arguments), should be a no-brainer to fix this.

some strange issues with module-loading during boot time (I fixed this by
explicitly loading the required modules again)

to be able to decrypt your partitions later. These may be built as modules
or statically into the kernel just like device mapper and device mapper crypt
portions of your kernel. If you chose to compile them as modules, you have to
load them accordingly in the hand-crafted initrd which has to be built after
the kernel compilation process

change to /usr/share/cryptsetup-initrd

adjust modules loaded in init (if necessary)

EXAMPLES

enter partitions that should be decrypted at boot time

example:

cryptsetup luksOpen /dev/hda2 root

When you finished tailoring init and initramfs.lst for your needs run:

A: check if your /boot is mounted. A fully encrypted '/' requires an
unencrypted /boot, thus it has to live on a partition of its own. This
partition has to be mounted correctly during lilo's installation into the MBR for
obvious reasons.

A: Because I did updates for all packages (to the current state) + the kernel (to
2.6.26) which included the patch for squashfs-3.3. I _do_ hope that this will
be helpful to the iso-building people (tilman, jaeger?), too.