4 ms·

Interesting! 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. N

by Nursie 4y ago

Interesting! 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.

Operative0198 4y ago
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. [0] https://github.com/Foxboron/sbctl https://github.com/Foxboron/sbctl [1] https://gist.github.com/kelvie/917d456cb572325aae8e3bd94a9c1350 https://gist.github.com/kelvie/917d456cb572325aae8e3bd94a9c1...
- Nursie 4y ago
  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.
  - Operative0198 4y ago
    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.
    - Nursie 4y ago
      > 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.
- patrakov 4y ago
  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.
  - Operative0198 4y ago
    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.
    - patrakov 4y ago
      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.
Arnavion 4y ago
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.
- Nursie 4y ago
  > An alternative to MokManager/shim is to enroll your own key. I was under the impression that that was exactly what I was doing with mokmanager/shim? dropping into a utility that would perform key enrolment? Perhaps I have seriously misunderstood!
  - vladvasiliu 4y ago
    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". I've found the Arch guide to be fairly clear: https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Using_your_own_keys https://wiki.archlinux.org/title/Unified_Extensible_Firmware... You should be able to adapt it to other systems.
    - Nursie 4y ago
      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!).
voidfunc 4y ago
What's the point of encrypting /boot exactly? From an Encrypt All The Things! perspective I get it, but practically... it seems overkill?
- vladvasiliu 4y ago
  Presumably to avoid tampering of the kernel and initrd, since GP doesn't use secure boot.
- Nursie 4y ago
  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?" So yeah - Encrypt all the things :)
  - rhn_mk1 4y ago
    You don't need to encrypt anything to verify those images, you just need to sign them. See how Heads does this. https://github.com/osresearch/heads https://github.com/osresearch/heads
    - Nursie 4y ago
      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?
vladvasiliu 4y ago
> 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 https://github.com/agherzan/yubikey-full-disk-encryption).
- teo_zero 4y ago
  Fascinating! How do you sign your kernel every time you recompile it? Do you need to store a new key into the UEFI every time?
  - vladvasiliu 4y ago
    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. [0] https://github.com/andreyv/sbupdate https://github.com/andreyv/sbupdate [1] https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Using_your_own_keys https://wiki.archlinux.org/title/Unified_Extensible_Firmware... [2] https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Fully_automated_unified_kernel_generation_and_signing_with_sbupdate https://wiki.archlinux.org/title/Unified_Extensible_Firmware...
webstrand 4y ago
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. https://build.opensuse.org/package/view_file/openSUSE:Factory/grub2/0009-Add-crypttab_entry-to-obviate-the-need-to-input-pass.patch https://build.opensuse.org/package/view_file/openSUSE:Factor... 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. My script for doing kexec with a preloaded LUKS password is here: https://gist.github.com/webstrand/381307348e24c28d5c4c9a5981871bd7 https://gist.github.com/webstrand/381307348e24c28d5c4c9a5981...

by Nursie 4y ago

Operative0198 4y ago

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. [0] https://github.com/Foxboron/sbctl https://github.com/Foxboron/sbctl [1] https://gist.github.com/kelvie/917d456cb572325aae8e3bd94a9c1350 https://gist.github.com/kelvie/917d456cb572325aae8e3bd94a9c1...

Nursie 4y ago
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.
- Operative0198 4y ago
  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.
  - Nursie 4y ago
    > 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.
patrakov 4y ago
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.
- Operative0198 4y ago
  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.
  - patrakov 4y ago
    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.

Arnavion 4y ago

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.

Nursie 4y ago
> An alternative to MokManager/shim is to enroll your own key. I was under the impression that that was exactly what I was doing with mokmanager/shim? dropping into a utility that would perform key enrolment? Perhaps I have seriously misunderstood!
- vladvasiliu 4y ago
  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". I've found the Arch guide to be fairly clear: https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Using_your_own_keys https://wiki.archlinux.org/title/Unified_Extensible_Firmware... You should be able to adapt it to other systems.
  - Nursie 4y ago
    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!).

voidfunc 4y ago

What's the point of encrypting /boot exactly? From an Encrypt All The Things! perspective I get it, but practically... it seems overkill?

vladvasiliu 4y ago
Presumably to avoid tampering of the kernel and initrd, since GP doesn't use secure boot.
Nursie 4y ago
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?" So yeah - Encrypt all the things :)
- rhn_mk1 4y ago
  You don't need to encrypt anything to verify those images, you just need to sign them. See how Heads does this. https://github.com/osresearch/heads https://github.com/osresearch/heads
  - Nursie 4y ago
    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?

vladvasiliu 4y ago

> 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 https://github.com/agherzan/yubikey-full-disk-encryption).

teo_zero 4y ago
Fascinating! How do you sign your kernel every time you recompile it? Do you need to store a new key into the UEFI every time?
- vladvasiliu 4y ago
  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. [0] https://github.com/andreyv/sbupdate https://github.com/andreyv/sbupdate [1] https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Using_your_own_keys https://wiki.archlinux.org/title/Unified_Extensible_Firmware... [2] https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Fully_automated_unified_kernel_generation_and_signing_with_sbupdate https://wiki.archlinux.org/title/Unified_Extensible_Firmware...

webstrand 4y ago

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. https://build.opensuse.org/package/view_file/openSUSE:Factory/grub2/0009-Add-crypttab_entry-to-obviate-the-need-to-input-pass.patch https://build.opensuse.org/package/view_file/openSUSE:Factor... 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. My script for doing kexec with a preloaded LUKS password is here: https://gist.github.com/webstrand/381307348e24c28d5c4c9a5981871bd7 https://gist.github.com/webstrand/381307348e24c28d5c4c9a5981...