LUKS with LVM: /dev/sda1 and mapper /dev/mapper/dm_crypt-0
Closed this issue · 5 comments
Hello,
I tried the guide from @ezaton and your script but it seems not to work for me. I always have to manual input the passphrase at boot.
What I couldn't find the guide + comments nor here is my setup. My encrypted disk is not the boot drive.
I have the following hierarchy using lsblk
sda 8:0 0 1,8T 0 disk
└─sda1 8:1 0 1,8T 0 part
└─dm_crypt-0 253:1 0 1,8T 0 crypt
└─vg0-lv--0 253:2 0 1,8T 0 lvm /home
This is in /dev/mapper:
dm_crypt-0 -> ../dm-1
ubuntu--vg-ubuntu--lv -> ../dm-0
vg0-lv--0 -> ../dm-2
And this is in /etc/crypttab:
dm_crypt-0 UUID=... none luks,discard,keyscript=/usr/local/sbin/tpm2-getkey,initramfs
I can only use /dev/sda1 as input for cryptsetup luksAddKey as for all other devices it says they are no LUKS devices. I tried /dev/sda1/dm-1 and /dev/mapper/dm_crypt-0. But /dev/sda1 seems to work as I have to enter my passphrase and it proceeds without errors.
But in /etc/crypttab I see dm_crypt-0 used which is not /dev/sda1.
My question: Is this combination a special case and the reason the guide nor the script does work? Any idea how could I fix it is much appreciated. Thanks!
Thats the output when the script gets confused:
Checking the saved key against the one in the TPM...
Adding the new key to LUKS. You will need to enter the current passphrase used to unlock the drive...
Device /dev/dm doesn't exist or access denied.
Something went wrong adding the encryption key to /dev/dm. Check /etc/crypttab and/or lsblk to determine your encrypted volume, then update this script with the correct value
Thanks for all the info, this is a great bug report!
So there are two potential issues at play here. As far as the script breaking, that is because of a commit changing it from a hard coded device e.g. /dev/sda3 to looping over devices in /etc/crypttab. Ubuntu usually names these like sda1_crypt, at least at install time, so the script looks for the part before the _ and assumes it is a device name. In your case, it sees dm_crypt-0 in crypttab, cuts that down to just dm and looks for /dev/dm, which of course fails.
I started going down a path a creating a whole menu system to select which drives you want and it was smart enough to take the name in crypttab and translate it into the actual device, rather than making assumptions. Unfortunately, I ran into what is likely your second issue.
When mounting the root drive, the boot system uses a facility that support the keyscript parameter. After it has mounted root, it hands over the rest of the mounting to systemd. From what I could tell (and I haven't worked on this in a couple months), systemd on Ubuntu supports neither keyscript nor TPM unlock. So even when the TPM key is added to the drives, I couldn't figure out how to systemd to unlock them without needing to type in the key. It might work if your drive was added to the same lvm group as your root drive, but I am not sure.
If you want to try the new menu version, you can get it on the alpha branch here: https://github.com/kelderek/TPM2-LUKS/blob/651c6fd9a0416b6f80356035cef784b2386ae8ee/tpm2_luks_boot_unlock.sh That should resolve the issue of the script failing, but unfortunately won't help with the issue of systemd not supporting keyscript parameters or unlocking automatically via TPM.
You could probably use a keyfile to unlock your non-root partitions as outlined here, but I haven't tried it:
https://vitobotta.com/2018/01/13/ubuntu-automatically-unlock-encrypted-drives-at-boot/
It wouldn't be directly protected by TPM, but if the keyfile is stored on root, and your root is protected by a key in the TPM, it would indirectly protect other drives...
I just saw this, which I hadn't seen before: https://github.com/archee565/Bytelocker
It might work better for you, but I haven't tried it. My suspicion is that it will have the same problem with non-root drives. For reference, this project uses nvread and nvwrite. The remarks at the bottom of the Bytelocker project about nvread and nvwrite being "wrong" because a USB boot could read them too is mitigated by our recommendation of disabling USB boot in the BIOS. Sealing a key in the TPM is definitely a better way of doing it and would allow you to run without the mitigation, so I will take a look at their code to see what I can learn! :)
Thanks for the feedback! At the end I decided to use the disk without encryption as it is installed on a server not a laptop.
Version 1.0.0 changes how the device is picked. It can either be specified on the command line or will now properly look up the drive based on the full volume name in /etc/crypttab instead of making assumptions about how it is named.