On 26/10/2022 15:51, Daniel P. Berrangé wrote: > On Wed, Oct 26, 2022 at 03:34:00PM +0300, Dov Murik wrote: >> >> >> On 26/10/2022 12:59, Daniel P. Berrangé wrote: >>> On Tue, Oct 25, 2022 at 07:38:43PM -0400, Cole Robinson wrote: >>>> On 10/19/22 6:17 AM, Daniel P. Berrangé wrote: [...] >>> Reading cryttab(5) I see that /etc/crypttab supports an option >>> called 'keyfile-size', which could be used to truncate the file. >>> That's not at all user friendly for us, as the user pw data can be >>> arbitrary length and when building the disk image template we >>> don't know how many bytes are sensitive.IOW, we can't predict >>> what keyfile-size to use. >>> >>> So it seems we have a few options >>> >>> 1. modify grub patches to remove the requirement for NUL >>> termination >>> 2. modify systemd to add a 'keyfile-nul-terminated' option >>> to instruct it to stip a trailing NUL from key-file. >>> 3. modify systemd to add a 'efi-secret=UUID' option and >>> ignore key-file field entirely >> >> Debian's crypttab supports keyscript=/path/to/script which should output >> the passphrase to stdout. This is very generic and can allow us to: >> >> 1. check a few GUIDs (fallback) >> 2. drop terminating NUL >> 3. for SNP-style late attestation: fetch attestation report, contact the KBS, >> and retrieve the key (see AMD's example [1]) >> >> [1] https://github.com/AMDESE/sev-guest/tree/main/attestation/cryptsetup-initramfs >> >> But there's no keyscript option in systemd... > > The keyfile path can, however, point to a AF_UNIX socket path. > So you can have a script on the other end of the path that does > anything at all. Still as per my earlier point, I find it very > appealing to have a solution not reliant on us writing an > extension script. Credit should be given to James who insisted that the efi_secret kernel module will expose a simple filesystem interface to read the secrets, which allows using crypttab's keyfile without other changes. I think this is the correct solution here. BTW one more thing a scripted approach can do (maybe not with keyscript=...) is unlink the coco/secrets/... file after cryptsetup luksOpen. efi_secret module will then remove the file entry and wipe the memory. This will prevent access to the disk passphrase (for example if an attacker got root access to *read* arbitrary files); maybe that's a security benefit. The downside is that it would prevent kexec or re-opening the luks partition. Aside, we can start thinking about initrd/cryptsetup for SNP/TDX attestation + secret retrieval which require network support, crypto, and more complex logic (which shouldn't be inside systemd). Maybe the clevis people have a plan for the more complex key releases (where the key is not simply a file). -Dov
