Back to wiki start page Categories: Development
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.).
$ fdisk /dev/hd? $ mkfs.???? /dev/hd?? $ mkswap /dev/hd??
$ 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
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)
enter partitions that should be decrypted at boot time
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:
lba32 install=text boot=/dev/hda image=/boot/26
label=CRUX root=/dev/hda1 read-only initrd="/boot/initrd-2.6.26" append="quiet"
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''?
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, ...)