4 ms·

If I wanted to keep Secureboot enabled, would signing with a MOK and enrolling that key be sufficient?

by Hasz 3y ago

Filligree 3y ago
You say that as though it's easy. I've yet to find an explanation that's shorter than a book.
- jchw 3y ago
  The truth is, it doesn't necessarily have to be a book long, but much like setting up PKI, it certainly can be. What we really need is simple tooling that handles just the case of "I want to sign kernels for my own machine(s)". Of course, some tools do exist for this case, but I'm not aware of one that is totally generic. Lanzaboote for NixOS seems interesting (disclaimer: have not tried.)
  - Filligree 3y ago
    It so happens I'm running NixOS... so thanks a lot for the reference! :D
    - schlarpc 3y ago
      Another option for NixOS is bootspec-secureboot, I'm using it with no real complaints: https://github.com/DeterminateSystems/bootspec-secureboot https://github.com/DeterminateSystems/bootspec-secureboot
      - predictabl3 3y ago
        Wait, wtf. There's this in addition to lanzaboote? But no mention of it? (And at one point there was another new list with bootspec support, maybe still is) Please, people, if you release software that overlaps or competes with another existing in the space, take the 3 minutes to write a comparison note or "why this exists". Please.
        withinboredom 3y ago
        Why should any project have to justify it's existence? Maybe it just scratches an itch?
        jchw 3y ago
        I will admit though, it being from Determinate Systems makes me wonder why they built it. They're not some hobbyists, they're a company built around making Nix tooling - and one of their most publicized tools, the Determinate Nix Installer, is actually a tool that, obviously, overlaps with existing tools, but has a very clearly stated objective and reason to exist. It seems very likely to me that there is, in fact, a reason for why they built this. If I had to guess, it's probably meant to be simpler, more robust, more elegant, etc. but I'd love to hear about it. Unfortunately, unlike many of their projects, they don't seem to have a blog post yet for it.
        predictabl3 3y ago
        I mean, at the very least, I do this because I make/release things because there's a gap to fill or an itch to scratch. And if I'm releasing something it's because I'm hoping it will be useful to others. It seems like a natural conclusion to spend a fraction of the energy to author, to detail it's reason to exist. Anyway, no one owes me anything but I trust that Determinate Systems has a grander vision than I can see, I just want to be clued in, to be honest ;).
- TacticalCoder 3y ago
  Ideally signing and enrolling in the UEFI the key to a signed Unified Kernel Image (UKI) makes more sense: only having SecureBoot verifying the kernel is okay'ish (and it does work: I tried modifying a single bit from my kernel and the UEFI refused to boot it) but it's not that great if the attacker can still modify the initrd etc.
  - rubicks 3y ago
    I thought "unified image" solved this? https://wiki.archlinux.org/title/Unified_kernel_image#Preparing_a_unified_kernel_image https://wiki.archlinux.org/title/Unified_kernel_image#Prepar...
    - DHowett 3y ago
      Indeed, that is what the parent is referring to when they say this: > Ideally signing and enrolling in the UEFI the key to a signed Unified Kernel Image (UKI) makes more sense (It's much more useful to have a link to it, so thank you!)
- chaosite 3y ago
  The Debian wiki explanation[1] is technical, but it's definitely shorter than a book, and if you're running your own kernels it shouldn't be too difficult. It gives you the "here, run these commands" version if that's what you want. [1] https://wiki.debian.org/SecureBoot#MOK_-_Machine_Owner_Key https://wiki.debian.org/SecureBoot#MOK_-_Machine_Owner_Key
- rubicks 3y ago
  Seconded. Step 0: deploy your own PKI, install certificates on your motherboard firmware, sign your kernel, sign your modules. Step 0.5: Sign your DKMSs from Broadcom, Nvidia, and Intel. Step 0.75: Re-sign everything because you missed a step.
- ungamedplayer 3y ago
  https://wmealing.github.io/signed-kernel-modules.html https://wmealing.github.io/signed-kernel-modules.html Maybe I need to write it a little more clearly, but perhaps that will get you there.
maurom 3y ago
It would seem so. Been doing that since a while on my laptop for locally compiled stable kernels from kernel.org. My hacky script has more lines to fetch the signer name from the kernel (once it's been signed) than to just sign the vmlinuz image.
andrewmackrodt 3y ago
I used to use https://github.com/berglh/ubuntu-sb-kernel-signing https://github.com/berglh/ubuntu-sb-kernel-signing and the mainline tool from cappelikan ppa, I think it worked on even with DKMS modules such as the Nvidia driver. I've since switched to xanmod with secure boot disabled do my memory is a bit hazy on that last point.

If I wanted to keep Secureboot enabled, would signing with a MOK and enrolling that key be sufficient?

by Hasz 3y ago

If I wanted to keep Secureboot enabled, would signing with a MOK and enrolling that key be sufficient?

Filligree 3y ago

You say that as though it's easy. I've yet to find an explanation that's shorter than a book.

jchw 3y ago
The truth is, it doesn't necessarily have to be a book long, but much like setting up PKI, it certainly can be. What we really need is simple tooling that handles just the case of "I want to sign kernels for my own machine(s)". Of course, some tools do exist for this case, but I'm not aware of one that is totally generic. Lanzaboote for NixOS seems interesting (disclaimer: have not tried.)
- Filligree 3y ago
  It so happens I'm running NixOS... so thanks a lot for the reference! :D
  - schlarpc 3y ago
    Another option for NixOS is bootspec-secureboot, I'm using it with no real complaints: https://github.com/DeterminateSystems/bootspec-secureboot https://github.com/DeterminateSystems/bootspec-secureboot
    - predictabl3 3y ago
      Wait, wtf. There's this in addition to lanzaboote? But no mention of it? (And at one point there was another new list with bootspec support, maybe still is) Please, people, if you release software that overlaps or competes with another existing in the space, take the 3 minutes to write a comparison note or "why this exists". Please.
      - withinboredom 3y ago
        Why should any project have to justify it's existence? Maybe it just scratches an itch?
        jchw 3y ago
        I will admit though, it being from Determinate Systems makes me wonder why they built it. They're not some hobbyists, they're a company built around making Nix tooling - and one of their most publicized tools, the Determinate Nix Installer, is actually a tool that, obviously, overlaps with existing tools, but has a very clearly stated objective and reason to exist. It seems very likely to me that there is, in fact, a reason for why they built this. If I had to guess, it's probably meant to be simpler, more robust, more elegant, etc. but I'd love to hear about it. Unfortunately, unlike many of their projects, they don't seem to have a blog post yet for it.
        predictabl3 3y ago
        I mean, at the very least, I do this because I make/release things because there's a gap to fill or an itch to scratch. And if I'm releasing something it's because I'm hoping it will be useful to others. It seems like a natural conclusion to spend a fraction of the energy to author, to detail it's reason to exist. Anyway, no one owes me anything but I trust that Determinate Systems has a grander vision than I can see, I just want to be clued in, to be honest ;).
TacticalCoder 3y ago
Ideally signing and enrolling in the UEFI the key to a signed Unified Kernel Image (UKI) makes more sense: only having SecureBoot verifying the kernel is okay'ish (and it does work: I tried modifying a single bit from my kernel and the UEFI refused to boot it) but it's not that great if the attacker can still modify the initrd etc.
- rubicks 3y ago
  I thought "unified image" solved this? https://wiki.archlinux.org/title/Unified_kernel_image#Preparing_a_unified_kernel_image https://wiki.archlinux.org/title/Unified_kernel_image#Prepar...
  - DHowett 3y ago
    Indeed, that is what the parent is referring to when they say this: > Ideally signing and enrolling in the UEFI the key to a signed Unified Kernel Image (UKI) makes more sense (It's much more useful to have a link to it, so thank you!)
chaosite 3y ago
The Debian wiki explanation[1] is technical, but it's definitely shorter than a book, and if you're running your own kernels it shouldn't be too difficult. It gives you the "here, run these commands" version if that's what you want. [1] https://wiki.debian.org/SecureBoot#MOK_-_Machine_Owner_Key https://wiki.debian.org/SecureBoot#MOK_-_Machine_Owner_Key
rubicks 3y ago
Seconded. Step 0: deploy your own PKI, install certificates on your motherboard firmware, sign your kernel, sign your modules. Step 0.5: Sign your DKMSs from Broadcom, Nvidia, and Intel. Step 0.75: Re-sign everything because you missed a step.
ungamedplayer 3y ago
https://wmealing.github.io/signed-kernel-modules.html https://wmealing.github.io/signed-kernel-modules.html Maybe I need to write it a little more clearly, but perhaps that will get you there.

maurom 3y ago

It would seem so. Been doing that since a while on my laptop for locally compiled stable kernels from kernel.org. My hacky script has more lines to fetch the signer name from the kernel (once it's been signed) than to just sign the vmlinuz image.

andrewmackrodt 3y ago

I used to use https://github.com/berglh/ubuntu-sb-kernel-signing https://github.com/berglh/ubuntu-sb-kernel-signing and the mainline tool from cappelikan ppa, I think it worked on even with DKMS modules such as the Nvidia driver. I've since switched to xanmod with secure boot disabled do my memory is a bit hazy on that last point.