[pkg-cryptsetup-devel] Bug#996181: cryptsetup-initramfs: Unable to use keyfile to decrypt rootfs

[Mateusz Jończyk]

Package: cryptsetup-initramfs
Version: 2:2.3.5-1
Severity: normal
Tags: patch

Hello,

Currently, it is not possible to use a keyfile to decrypt the root file system. I would like to use such a setup, so I'm attaching a short patch for crypttab to make this work.

The root filesystem may reside on more then one LUKS volume and it is cumbersome to type the password twice on each boot. I'm using such a setup: I have two drives in my laptop: on each one of them I have an encrypted LUKS partition, on every LUKS partition I have several LVM logical volumes. Two of these logical volumes (one from every physical drive) are setup in a RAID1 array, on which my rootfs resides.

See also bug #928943 for another setup example.

Using a keyfile on the first volume to decrypt the second one does not make it necessary to type the password twice on boot.

I'm using Ubuntu 20.04 as the main system on my laptop, but I have reproduced and fixed this problem in a Debian 11 virtual machine - to fix it upstream.

Probably the best solution would be to allow decrypting more then one LUKS container with a single password. This will also make converting existing systems to encrypted storage easier. I'll try to add relevant support to cryptsetup-initramfs and post a separate patch.

The output of "lsblk" in the test VM:

NAME            MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda               8:0    0   10G  0 disk  
├─sda1            8:1    0  487M  0 part  
│ └─md0           9:0    0  486M  0 raid1 /boot
└─sda2            8:2    0  9,5G  0 part  
  └─10Ga        253:0    0  9,5G  0 crypt 
    ├─10Ga-root 253:1    0  9,3G  0 lvm   
    │ └─md1       9:1    0  9,3G  0 raid1 /
    └─10Ga-key  253:2    0   12M  0 lvm   
sdb               8:16   0   10G  0 disk  
├─sdb1            8:17   0  487M  0 part  
│ └─md0           9:0    0  486M  0 raid1 /boot
└─sdb2            8:18   0  9,5G  0 part  
  └─10Gb        253:3    0  9,5G  0 crypt 
    └─10Gb-root 253:4    0  9,3G  0 lvm   
      └─md1       9:1    0  9,3G  0 raid1 /
sr0              11:0    1 1024M  0 rom   


-- Package-specific info:
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-5.10.0-9-amd64 root=/dev/md1 ro quiet

-- /etc/crypttab
# <target name>	<source device>		<key file>	<options>
10Ga /dev/sda2 none luks,initramfs
10Gb /dev/sdb2 /dev/mapper/10Ga-key luks,initramfs,keyfile-size=512

-- /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# systemd generates mount units based on this file, see systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/md1 during installation
UUID=c010b6e7-72b7-4237-acfa-c4071d82a804 /               ext4    errors=remount-ro 0       1
/dev/md0	/boot	ext4	errors=remount-ro	0	1
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0
debian	/root/host	9p	nofail	0	0

-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/1 CPU thread)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- debconf information excluded
-------------- next part --------------
>From 4529b33c3e4c47f9124c7426d5bb9d530954b812 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mateusz=20Jo=C5=84czyk?= <mat.jonczyk at o2.pl>
Date: Sun, 10 Oct 2021 22:27:56 +0200
Subject: [PATCH] debian: allow using key file to decrypt rootfs

There are some cases when someone would like to use a key file to unlock
the root filesystem. One of them is when the key file is a partition on
a pendrive. Another one is when the key file is on an encrypted device
(possibly an LVM logical volume) that was unlocked by a previous
crypttab entry.

In both of these examples, the key file is accessible on /dev, so do
not mangle it with "/FIXME-initramfs-rootmnt" if that's the case.
---
 debian/initramfs/hooks/cryptroot | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/debian/initramfs/hooks/cryptroot b/debian/initramfs/hooks/cryptroot
index 81f65869..9e3d67a8 100644
--- a/debian/initramfs/hooks/cryptroot
+++ b/debian/initramfs/hooks/cryptroot
@@ -82,8 +82,7 @@ crypttab_print_entry() {
                 ;;
             *)
                 if [ "$usage" = rootfs ]; then
-                    cryptsetup_message "WARNING: Skipping root target $CRYPTTAB_NAME: uses a key file"
-                    return 1
+                    cryptsetup_message "WARNING: Root target $CRYPTTAB_NAME uses a key file"
                 elif [ "$usage" = resume ]; then
                     cryptsetup_message "WARNING: Resume target $CRYPTTAB_NAME uses a key file"
                 fi
@@ -97,8 +96,9 @@ crypttab_print_entry() {
                 fi
                 if [ ! -e "$CRYPTTAB_KEY" ]; then
                     cryptsetup_message "WARNING: Target $CRYPTTAB_NAME has a non-existing key file $CRYPTTAB_KEY"
-                else
-                    _CRYPTTAB_KEY="/FIXME-initramfs-rootmnt$_CRYPTTAB_KEY" # preserve mangled name
+                elif [ "$(stat -L -c"%m" -- "$CRYPTTAB_KEY" 2>/dev/null)" != "/dev" ]; then
+                    # mangle the name, if the key is not on /dev
+                    _CRYPTTAB_KEY="/FIXME-initramfs-rootmnt$_CRYPTTAB_KEY"
                 fi
         esac
     fi
-- 
2.25.1