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-initram...
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