Install Qubes OS with boot partition and a detached LUKS header on USB

Community Guides
61

Hi. Actually no. I do not need this much security measures at this moment. But if I ever do implement a similar feature, for sure I will write a guide on this.

62

I used the setup from this guide several times with no problems in the past, but in 4.3 RC2 it somehow didnā€™t work this time. Somehow after finishing the setup and rebooting the system, I got a boot failure.
Not sure if something changed in the new release or if I did something wrong this time, but essentially I had to put these lines in /etc/dracut.conf.d/crypt.conf:

add_dracutmodules+=" crypt "
install_items+=" /root/header.img /usr/sbin/cryptsetup /etc/crypttab "

And in /etc/crypttab:

luks /dev/disk/by-id/ata-YOUR_DISK_ID none header=/root/header.img,force,x-initrd.attach,discard

Then it worked again.

Additionally, because of the new policy system in 4.3, I wasnā€™t able to attach my USB to dom0 anymore. I tried to add a policy in the Qubes Policy Editor:

30-allow-dom0-block

qubes.BlockList * dom0 sys-usb allow
qubes.BlockAttach * dom0 sys-usb allow
qubes.BlockDetach * dom0 sys-usb allow

But somehow that didnā€™t work. Not sure if there is a bug or I made a mistake. But for now I helped myself by updating with this command:

qvm-run -u root sys-usb 'umount -f /dev/sdX1 2>/dev/null || true; umount -f /dev/sdX2 2>/dev/null || true; mkdir -p /mnt/boot/efi; mount /dev/sdX2 /mnt/boot; mount /dev/sdX1 /mnt/boot/efi' && sudo qubes-dom0-update && sudo tar -C /boot -cpf - . | qvm-run --pass-io sys-usb 'sudo tar -C /mnt/boot -xpf -' && qvm-run -u root sys-usb 'sync; umount /mnt/boot/efi /mnt/boot'`
2 Likes
63

Same here, the guide is still golden for 4.2, but not for 4.3

I had all the issues that @merowing mentioned. I think thereā€™s something wrong with ā€œgetting password for disk encryptionā€, and my keyboard didnā€™t work (it works in grub and dracut emergency shell).

Luckily the update tool automatically created a LVM snapshot, and I was able to revert to it.

1 Like
64

I did a bit more research, my findings:

  • I read that when systemd modules is enabled in dracut, it uses systemd-cryptsetup, which is an independent implementation from cryptsetup, so it is natural that /usr/sbin/cryptsetup is not enabled. (I observed that systemd has been running in the dracut emergency shell)
  • Supposedly dracut should pick up entries from /etc/crypttab.initramfs and generate /etc/crypttab for initramfs. Maybe adding an entriy in /etc/crypttab.initramfs might help.
  • Since systemd is enabled, maybe we can try systemd-cryptsetup-genertor parameters instead of /etc/crypttab

Other rumors: (I have not tested them):

  • Enable rd.hostonly
  • Make sure the first line of /etc/crypttab is not comment
  • Add an entry of /
1 Like
65

I have this dracut config, and it is working:

  • 10-nvme.conf, content: add_drivers+=" nvme "
  • crypt.conf, content: add_dracutmodules+=" crypt "
  • 15-compress.conf, content: compress=ā€œzstd -1ā€
  • lvm.conf, content: add_dracutmodules+=" lvm "
  • 99-hostonly.conf, content: hostonly=ā€œnoā€
  • 10-crypt.conf, content: install_items+=" /etc/keys/key_dom0 /etc/crypttab /etc/keys/header_dom0 "
1 Like
66

I checked my working dracut config again and it actually looks like this:

add_dracutmodules+=" crypt "
install_items+=" /root/header.img /usr/sbin/cryptsetup /etc/crypttab "
hostonly=no

So this and the entry x-initrd.attach in /etc/crypttab are the only things I changed from the original guide, but I donā€™t know which additional entry actually caused it to work for me.

If I had to guess, I would say itā€™s the entry /etc/crypttab. Iā€™ve read that dracut doesnā€™t always reliably include crypttab automatically in all setups. Therefore itā€™s probably more reliable to include it explicitly. /usr/sbin/cryptsetup is not necessary I guess, but it doesnā€™t hurt either.

But using systemd-cryptsetup-generator parameters is probably also a good alternative.

1 Like
67

I found a working config for me: simply changing crypt to systemd-cryptsetup, no need to include other files.

Relevant bugs:

Basically itā€™s what I suspected, that thereā€™s a bug where crypt module doesnā€™t work if systemd is enabled.

Iā€™ve been also wondering why we have to manually add crypt or systemd-cryptsetup. After studying the code, my theory is the detached header prevents dracut from automatically detecting the filesystem type.

@merowing Iā€™m not sure why your config works for you but not for me. Iā€™d guess either you donā€™t have systemd module enabled, or you have some other LUKS encrypted devices (without detached header), which makes dracut to include systemd-cryptsetup. Perhaps you can verify using lsinitrd /boot/initramfs-...

1 Like
68

I found a workaround for the USB issue: Cannot attach `sys-usb` devices to dom0 Ā· Issue #10361 Ā· QubesOS/qubes-issues Ā· GitHub

2 Likes
69

I think hostonly=no also affects the decision. Perhaps you can verify systemd-cryptsetup module is included.

1 Like
70

Thanks for the USB workaround! That helped.

Well I donā€™t have any other LUKS devices.
If I understand correctly, you upgraded from 4.2 to 4.3 right? Because I did a clean install of 4.3. Maybe that changed something? I donā€™t know. But itā€™s good that it worked out for you now too.

This is what lsinitrd -m /boot/initramfs-$(uname -r).img | egrep -i 'crypt|systemd' is showing:

systemd 
fips-crypto-policies 
systemd-ask-password 
systemd-initrd 
systemd-journald 
systemd-modules-load 
systemd-pcrphase 
systemd-sysctl 
systemd-sysusers 
systemd-tmpfiles 
systemd-udevd 
crypt 
systemd-cryptsetup 
dracut-systemd
1 Like
71

I see, so systemd-cryptsetup is also enabled in your setup. I donā€™t know what triggered it, but it confirms my theory (that crypt itself doesnā€™t work when systemd is enabled).

1 Like
72

Iā€™m having trouble figuring out which commands to change for 4.3, can someone make a post with the systemd-cryptsetup commands and files?

Also it looks like they fixed the USB issue in November, so now the first postā€™s attach command should work by default now right?

1 Like
73

Can this be combined with Heads? Is there any documentation or gotchas other than changing the boot device to the usb (/dev/sda or sdb, etc. depending on your disk setup)? I searched this topic for ā€˜headsā€™, as well as a search engine, and didnā€™t find anything relevant, and I skimmed the thread, but itā€™s a long one so pardon me if this is elsewhere. @Insurgo ?

Also, would it be theoretically possible to have multiple machines use the same USB for the detached /boot and header?