Add details for use of cryptsetup keyfiles

[jinnko]

If the system is to be unlocked with keyfiles then an additional step is needed to work around the fact cryptsetup doesn't handle ZFS devices any more.

[rlaager]

A few thoughts/requested changes:

1. Typo on line 665 "initrmafs".
2. This feels like half of the instructions. It talks about if you're doing this but does anywhere in the instructions tell you how to setup keyfiles?
3. Are you decrypting the root filesystem with a keyfile stored in the initramfs? As your note says, that's insecure. So, what's the point of this?

[jinnko]

Thanks for the feedback @rlaager.

1. Typo on line 665 "initrmafs".

Fixed

2. This feels like half of the instructions. It talks about if you're doing this but does anywhere in the instructions tell you how to setup keyfiles?

There are many ways and guides to do this. Rather than adding to the variety I've linked back to the official Debian documentation provided by the cryptsetup team that references keyfiles. I was unable to find any other official documentation.

3. Are you decrypting the root filesystem with a keyfile stored in the initramfs? As your note says, that's insecure. So, what's the point of this?

In the case of keyfiles, if the /boot volume where the initramfs is stored is encrypted then there's no concern. This is possible with recent versions of Grub where a passphrase is requested for Grub to decrypt the boot volume. In turn the initramfs can then decrypt multiple volumes via the keyfiles - and thus only a single passphrase need be entered at boot time. This is described in the linked official Debian documentation.

In the case of keyscripts - the script could, for example, use a hardware token to decrypt the disk or get an unlock key from a network endpoint.

[rlaager]

I'm still hesitant about this. It still feels like a half-answer. I'm hesitant to add something that I haven't tested (and without an obvious example of how to use it, it's a bunch of extra work for me to test it, meaning I likely won't).

[jinnko]

@rlaager - I appreciate you want this to be robust and reasonable. I'm willing to do what's necessary to get this into a good place as I believe this will be useful to others in a similar situation.

In terms of being able to test this, I had previously put together an automated vagrant test set up. It has not been updated in a while and so doesn't include the necessary set up for Debian Bullseye. It is at https://github.com/ixydo/vagrant-zfs-on-linux. I'd be happy to update the repo to cover the scenario we're dealing with here, and on Debian Bullseye, which should make testing much easier.

The reason I original raised this PR was because I maintain some systems running ZFS on LUKS from before native encryption existed. Those systems have been upgraded in place for years and during the upgrade to Debian Bullseye this issue had to be resolved, which took the better part of the day to debug. The scenario is that the systems have RAID-10 arrays on ZFS, with hot spares. Managing this without keyfiles or keyscripts is cumbersome hence converging on a single unlock of the bootloader which in turn unlocks access to the rest.

It was the references in the OpenZFS documentation to the lack of support for ZFS root filesystems on LUKS in cryptsetup that helped me dig in the right place to find the source of the issue. In an ideal world the fixes would be implemented in cryptsetup, but the maintainers there don't want to take on the responsibility, which given the controversy between OpenZFS and linux - is somewhat understandable.

If you're open to the vagrant approach I'll get that updated when I find some time in the next few weeks and update here again when it's ready.

[jinnko]

This alternative format crypttab is no longer required. Not sure why - it may have been a result of rolling upgrades or it may have been fixed somewhere else 🤷🏽

Closing this PR.