I went on a similar journey recently with debian and FDE on luks2, which involved a fair amount of learning and messing around, but I got there. No Btrfs though, just plain old ext4+swap volumes using lvm on luks2, and a small uefi partition.
My /boot is encrypted so I enter the LUKS2 passcode before grub can even access its config, and I've rolled an unlock key into the initramfs (which is loaded by grub from the encrypted partition) so that I don't have to enter it twice. The only cleartext stuff is /boot/efi.
Next project is secure boot, but so far I have failed to add a MOK to my system (it just doesn't seem to persist for some reason), and I've not got any further than shim->grub->FAIL.
Hibernate is less interesting, and apparently unsupported using secure boot anyway.
> Hibernate is less interesting, and apparently unsupported using secure boot anyway.
That's not the case. I have a similar setup to yours (/ on ext4 with separate swap, on LVM on LUKS, separate /efi) and my box hibernates just fine with secure boot and auto-unlock via TPM.
The difference with your setup is I don't use grub, but have the UEFI load a signed unified kernel image directly. Since this works so well, I never had a reason to mess around with yet another moving piece (grub or other bootloader).
As another commenter said, I haven't attempted to mess around with the MOK. I just replaced all the secure boot keys with my own, and I've also signed MS's Windows key (but not the 3rd party one) for my dual-boot needs.
---
For specifics: This is an up-to-date Arch Linux install, running on an HP EliteBook 840 G8 (11th gen intel). I know Debian may have older components than arch, but this setup has been working for more than a year now.
IIRC, the most significant change was brought by systemd 251 which started supporting auto-unlocking LUKS with the TPM. Before that, on an older computer with the same general setup, hibernation worked well, too. I just needed to input the unlock password (which I was too lazy to do, so I just used my yubikey - see https://github.com/agherzan/yubikey-full-disk-encryption).
The point is that the PC boots up fully unattended. People could access my data without a password if they stole my machine and somehow managed to log in to it, say through a bug in the desktop manager on the login process. The LUKS key is in memory, so I guess if they can somehow read that, they could also access the drive. But I figure the convenience is worth it, I don't expect to be a high-level target for this. And if I were, the 5$ wrench attack would probably work better.
If they stole the hard drive, they wouldn't be able to access the data, the TPM wouldn't release the key.
I use sbupdate [0] to build the unified kernel image and to sign it with my keys. It's run by a hook in the arch's package manager whenever the kernel, the initrd or the firmware images change. I saw the other day that systemd recently got an utility to do this, but I've never looked into that. sbupdate has been working fine for me for several years now.
It doesn't store a new key in the uefi, it signs the new image with the key that uefi already knows about.
See [1] for the whole setup and [2] for the signing part specifically.
For secureboot you may want to took a look at this project [0]. Don't think it has ever gotten easier to sign UKIs than that though systemd should have a new project (systemd-ukify) that aims to make it more integrated.
Hiberation is not supported in lockdown mode because I'm assuming the kernel (maintainers) expect most people to have an unencrypted swap partition. If you have secured your swap, you can patch [1] the kernel to allow hibernation.
Thanks, yeah I think I came across sbctl when I was playing around with it. Haven't tried it yet... it got a little confusing when I was reading various guides to try to achieve what I've been trying to achieve, and they started referring to various different tool sets!
I'll have a go with it to enroll some keys and see if they persist. mokutil, and then rebooting into shim to persist them, has failed me. It all seems to go OK and then they're just not there on the next boot.
On hibernation, that makes sense. I hadn't read into the reasoning, just got as far as "MS allows it in secure boot mode, linux devs consider it insecure by design" or some such thing.
You don't need any other tools sets when using sbctl to enroll and sign your keys. It's a one-stop shop for creating UKI bundles and signing them. I use systemd-boot with UKIs created by it and it has no issues detecting the UKIs. Maybe your problem is holding on to grub(legacyware IMO) which has poor support for what you are trying to accomplish.
Hibernation support in lockdown has nothing do with the MS politics around secure boot. You can generate and use your own keys to use with secureboot. The issue is that "accessible" unencrypted hibernation files invalidate secureboot when you can break into RAM and modify system images/files.
> Maybe your problem is holding on to grub(legacyware IMO)
My problem is that I can't enroll keys, going through the enroll procedure (which doesn't involve grub) results in ... nothing.
I'm not specifically wedded to grub, and a UKI signed with a key is a fine idea if I can get a key installed. As such, I'll try sbctl but I have no particular reason to think it will work where shim/mokmanager fail if there's a motherboard issue of some sort.
There may well be challenges using grub down the line, but right now I'm not even getting far enough for that to be an issue.
It is not because of an unencrypted swap partition. It is because, even if it is encrypted, you know the key and can thus replace the image with an arbitrary modified one, or, in theory, with a hacked version of a Windows boot loader, which would break DRM.
There were some movements to remove this restriction, on the condition that the encryption key is properly sealed in the TPM and is not extractable.
Except you'd have to know the encryption passphrase to unlock the swap partition. Only after this step can you use the stolen key to manipulate the state of trusted images.
TPM has never been a pre-requisite for secureboot nor kernel_lockdown. Infact the proposal you are speaking of sounds very exclusionary since TPM hardware is still relatively new and not ubiqitous.
Correct. But you do know the passphrase, and, from the viewpoint of Secure Boot and the locked-down kernel, you (the legitimate owner) are also the attacker who tries to run some unapproved kernel-mode code and will stop at nothing in order to do that.
An alternative to MokManager/shim is to enroll your own key. You'll also need to convince your kernel package to create a UKI under /efi instead of regular initramfs under /boot, and to sign the UKI with your key.
Eg on my OpenSUSE system, the kernel package runs dracut to build the initramfs in /boot, and it's three lines of config to co-opt dracut to build a UKI in /efi and sign it with my key instead. So installing a kernel package automatically creates the UKI in /efi, and systemd-boot automatically notices it on next boot.
Debian doesn't use dracut by default, but it does have hooks in /etc/kernel/postinst.d which should let you do the same thing.
I'd expect "MokManager" to... manage the MOK. Never used it, though. For one PC whose UEFI was recalcitrant, I've had to use another tool, called "KeyTool". It may or may not be the same thing, but mine let you change multiple kinds of keys, and, in particular, the platform key (aka the "root" key).
There are several steps. First, you usually have to put the UEFI in "custom mode", where you install your keys and end with the Platform Key. You typically get some kind of warning when enrolling the PK similar to "this will get the system out of custom mode".
MOK is short for Machine Owner Key, which is just a way of saying "a key you enroll in your UEFI secure boot variables that is under your control".
Or that's what I thought anyway, if it's not actually doing that, and is just enrolling them in some sort of shim-internal DB, then it's a lot less interesting and I'll abandon that approach...
I don't necessarily want to change the 'root' PK ... or maybe I do if it's the only way to install a machine-owner trusted key in the real UEFI... I'll look at KeyTool in case it makes saving a key under my control to the db easier/actually work. Though the keytool I'm familiar with is a java pkcs#12 manipulation tool!
(on further reading, it looks like shim/mokutil creates a new key-set in nvram, separate to the UEFI stuff, that it manages itself and uses internally. This is not what I was trying to achieve and seems very much like vendor lock. I surely shouldn't need to use shim to boot if I'm signing stuff with my own keys... and it doesn't seem like it has even managed to persist this custom keyset. Back to the drawing board!).
As you already discovered in the other comment, the root Secure Boot key is the PK, and the MOK is a concept that shim made up. shim was created so that people didn't have to enroll their own PK, if their firmware even let them do that in the first place. Every distro that uses shim was able to get it signed by Microsoft (MS would not sign each and every bootloader in existence, and especially not any version of grub), and then shim does its own verification of the next stage application using the MOK DB.
OpenSuse's got a neat patch for grub that copies the password you enter at boot into the initrd. This way you don't need to store a key in your initrd and you don't need to worry about securing those initrd against theft.
Side note, you can use this same technique to add the LUKS password to the initrd just before doing kexec. This lets you reboot a remote system protected this way without having to pull up a VNC to enter the password.
As the other poster mentioned, without secure boot, there are no guarantees about a kernel or initramfs that are sitting out there in plaintext (and yes, someone could mess with my grub install).
It was mostly because "this should be possible, right?"
Sure, and you could do that with more or less your whole installed system.
From the other angle - if it’s not a lot more difficult than encrypting the rest, why would I specifically exclude having these stored on an encrypted volume?
I went on a similar journey recently with debian and FDE on luks2, which involved a fair amount of learning and messing around, but I got there. No Btrfs though, just plain old ext4+swap volumes using lvm on luks2, and a small uefi partition.
My /boot is encrypted so I enter the LUKS2 passcode before grub can even access its config, and I've rolled an unlock key into the initramfs (which is loaded by grub from the encrypted partition) so that I don't have to enter it twice. The only cleartext stuff is /boot/efi.
Next project is secure boot, but so far I have failed to add a MOK to my system (it just doesn't seem to persist for some reason), and I've not got any further than shim->grub->FAIL.
Hibernate is less interesting, and apparently unsupported using secure boot anyway.