Back to wiki start page Categories: Development

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)

General outline of the new setup process

old

  $ fdisk /dev/hd?
  $ mkfs.???? /dev/hd??
  $ mkswap /dev/hd??

new

  $ fdisk /dev/hd?
  $ modprobe dm-crypt
  $ cryptsetup luksFormat /dev/hd??
  $ cryptsetup luksOpen /dev/hd?? name
  $ mkfs.???? /dev/mapper/name

from now on, don't use /dev/hd?? for mounting but the newly created/'luksOpen-ed' /dev/mapper/name device node

install:

libdevmapper cryptsetup-initrd cryptsetup libgcrypt popt

(or just everything from core and opt for testing)

kernel configuration It is recommended to include all necessary features 'statically', i.e. not as modules.

say at least yes or module to

General setup --->

  [*] Initial RAM filesystem and RAM disk (iniramfs/initrd) support

Device Drivers --->

  Multiple devices driver support (RAID and LVM) --->
    [M/*] Device mapper support
    [M/*] Crypt target support

Note: you also have to include the desired

  Block modes
  Hash modes
  Digest
  Ciphers

in Cryptographic API --->

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:

$ sed -e "s/#KERNEL_VERSION#/`uname -r`/g" initramfs.lst > initramfs.lst-SED $ /usr/src/linux-`uname -r`/usr/gen_init_cpio initramfs.lst-SED > initrd $ cp initrd /boot

(alternative: cp initrd /boot/initrd-`uname -r`)

adjust your bootloader's config:

1. lilo.conf

lba32 install=text boot=/dev/hda image=/boot/26

  label=CRUX
  root=/dev/hda1
  read-only
  initrd="/boot/initrd-2.6.26"
  append="quiet"

$ lilo

cross your fingers and reboot. From now on CRUX won't boot if the correct

Because I repeated some (stupid) mistakes during the course of implementation and testing, I created a small FAQ for you to save time.

Q: I type in the correct password but cryptsetup only returns: Command failed: No key available with this passphrase. What is wrong?

A: Load the dm-crypt module and the according module for the cipher you chose to encrypt your partition with.

Q: Why may I not use /dev/hda[0-9] as mount point after I encrypted it with cryptsetup(1)?

A: Do not use the encrypted device node but the (transparently) decrypted (i.e. ``luksOpen''-ed) device located in /dev/mapper/*. It is created after running e.g.

    cryptsetup luksOpen /dev/hda2 name

If the correct passphrase is supplied, a new device /dev/mapper/name will appear which can be mounted, mkfs'd and so on.

Q: LILO complains: ``Fatal: device-mapper: only linear boot device supported''

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.

Now. Where's the links, because ``send links or it didn't happen''?

https://serverop.de/~tek/crux-dmcrypt/

Q: Why did you call it 2.4.9?

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.

I will very glady share a git diff for my /usr/src/iso - repo

Feedback is very welcome (IRC, Mail, Edits here, ...)