FOG Secure Boot with Shim

[KMEH]

@jmeyer Now worries, it gets a little confusing, and sorry for the late reply again, I was on Holiday last week so didn’t check the forums for a while. I believe that shim should already be signed and you should be able to use it. You should already have the signed shim package installed which would provide that file I would imagine, though I’m not familiar with Debian to say that with any certainty. However, that shim would need to be copied into the /tftpboot folder and it’s permissions changed accordingly. Remember to renamed your ipxe binary to grubx64.efi or whatever the Debian shim is programmed to automatically chainload.

[Florent]

@KMEH
Hi,
I don’t understand well evereything too, but thanks for your work and research on this.
On the last IPXE release 2.0 (https://github.com/ipxe/ipxe/releases), i see

Add support for UEFI Secure Boot via a dedicated iPXE shim.

Does this mean that if FOG include this last ipxe release, Secure Boot support for FOG will be handled automatically?

[KMEH]

@Florent Hi Florent,

I actually have been meaning to look into this some more, but the likely answer is no, or at least, not entirely. The way that support works is, you download a signed iPXE 2.0 binary from iPXE and a copy of their signed shim. That shim is signed with the Microsoft keys and trusts the iPXE signing keys. What this means in practical terms is, all the steps above would still need to occur, it’s just that the signing of the iPXE binary is managed by iPXE, and you don’t need to enroll a key to boot iPXE.

That said, I would imagine this only covers you for booting iPXE, any chainloaded binaries would still need to be signed either with Microsoft’s key or a MOK key you’ve enrolled on the machine. In FOG’s case this means the FOS kernel has to be signed and trusted on the system, in addition to any other binaries (for example memtest, refind) you plan to boot via FOG.

The other likely blocker is the build itself. Naturally, only iPXE can sign binaries that the iPXE Shim will support. Currently the FOG installer actually builds a slightly modified iPXE binary from source. While I’m unsure if these are all that different from the pre-built binaries from 2.0 in terms of support and functionality, it would at the very least need to be changed to instead pull the iPXE 2.0 binaries.

I don’t think any of these are particularly hard to overcome or deal with though. The bottom line is, 2.0 makes it easier, but only to a point. To get real proper Secure Boot support in FOG, they’ll likely need to generate their own signing keys, and start signing at least the FOS kernels (if not iPXE itself) and update FOG to include shim support somehow.

That said, for basic support, I doubt they would need to go the full mile and get a Microsoft approved signing key, I think distributing a certificate/key you can enroll via MokManager and using a pre-existing signed shim (like the iPXE provided one) would more than suffice for most usecases. I’m not sure how difficult it would actually be to implement any of this into FOG, that’s a question for someone who knows PHP and is more familiar with the FOG codebase than I.

Sorry if that’s a bit long winded, it’s not an easy topic to distill. Hope that helps though.

[jmeyer]

@Florent @KMEH
First problem I see in the ipxe release is “x86-64 UEFI Secure Boot only”.
So, if SB is not enable, it doesn’t work at all ?
It also means that we need to make a SB check to say what efi file the computer need to use ?

I’ll have some time this week, I’ll try make some tests.

[KMEH]

@jmeyer I haven’t tested it at all myself, but I wonder if that is referring to the fact that if Secure Boot is turned on all binaries (even the chainloaded ones such as the linux kernel) must be Secure Boot compatible. I’ll be interested to hear of your tests.

[jmeyer]

Here is my first steps.

Install signing tools on your FOG server

apt update
apt install sbsigntool openssl mokutil

Install shim & grub

apt install shim-signed grub-efi-amd64-signed
cp /usr/lib/shim/shimx64.efi.signed /tftpboot/shimx64.efi
cp /usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed /tftpboot/grubx64.efi

I end with this at PXE boot :

Shim signature give this : (sbverify --list shimx64.efi)

warning: data remaining[831016 vs 957136]: gaps between PE/COFF sections?
signature 1
image signature issuers:
 - /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows UEFI Driver Publisher
   issuer:  /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
   issuer:  /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root

and grub sinature return :

signature 1
image signature issuers:
 - /CN=Debian Secure Boot CA
image signature certificates:
 - subject: /CN=Debian Secure Boot Signer 2022 - grub2
   issuer:  /CN=Debian Secure Boot CA

I tried creating MOK key but I’m stuck with security violation :

mkdir /root/secureboot
cd /root/secureboot
openssl req -new -x509 -newkey rsa:2048 -keyout FOG-MOK.key -out FOG-MOK.crt -nodes -days 3650 -subj "/CN=FOG Secure Boot/"
openssl x509 -in FOG-MOK.crt -outform DER -out FOG-MOK.der

FOG-MOK.key <-- private key (protect!)
FOG-MOK.crt
FOG-MOK.der <-- enroll this on clients

Sign ipxe.efi and rename it to grubx64.efi

cd /tftpboot
cp ipxe.efi ipxe.efi.original
sbsign --key /root/secureboot/FOG-MOK.key --cert /root/secureboot/FOG-MOK.crt /tftpboot/ipxe.efi --output /tftpboot/ipxe-signed.efi
cp ipxe-signed.efi grubx64.efi

I think I need to work more and as Fog default exit type is refind, I’ll make more research.

[jmeyer]

I remplaced grubx64 by grubnetx64 (not sure if needed but was recommanded for PXE) and create a “grub” directory in tftpboot with “grub.cfg” inside.
Grub signed look for cfg file in a subdir called “grub” by default.

cp /usr/lib/grub/x86_64-efi-signed/grubnetx64.efi.signed /tftpboot/grubx64.efi
mkdir /tftpboot/grub
chmod -R a+rX /tftpboot/grub

I get grub menu.

update (10 am) :
I copied snponly.efi in grub directory and signed it with the FOG-MOK key I generated before.

sbsign --key /root/secureboot/FOG-MOK.key --cert /root/secureboot/FOG-MOK.crt /tftpboot/snponly.efi --output /tftpboot/grub/snponly.efi

I end with “error ; bad shim signature”.
I think I need to import the key on the computer with command “mokutil --import /chemin/vers/FOG-MOK.der”

I keep on searching…

2nd update (12:30 am):

To enroll key :

cp /usr/lib/shim/mmx64.efi.signed /tftpboot/mmx64.efi

and in tftpboot/grub/grub.cfg

menuentry 'Enroll MOK' {
    insmod tftp
    insmod chain
    chainloader (tftp,192.168.69.10)/mmx64.efi
    boot
}

menuentry 'Boot FOG (iPXE)' {
    insmod efinet
    insmod tftp
    insmod chain
    net_bootp
    chainloader (tftp,192.168.69.10)/grub/snponly.efi
    boot
}

Copy the .der on usb key, put it on the computer, run “Enroll MOK” in pxe grub menu then “Enroll from disk”
Reboot and run “Boot FOG” in pxe menu.

And at least I have the FOG menu !
I think I’m in the right way.

Let’s keep on working.

[KMEH]

@jmeyer Good work. So far looks very similar to what I was doing above but with grub instead. I’m guessing you’re aiming for something along the lines of the archived project you mentioned earlier that did this. Make sure you modify your ipxe scripts to load the shim with the shim command, and then sign whatever you’re booting from ipxe and you should be more or less there.

It’s worth noting if you want you should be able to skip the grub stage entirely, if you load the shim directly and name your ipxe binary what you’re grub binary currently is you should be able to net boot any shim pretty easily, from there the shim can automatically call mok manager as long as it’s in the same directory as your shim.

Sorry for responding so late. I’m out on training this week.

[KMEH]

So, somehow this slipped by my radar, but this guide is now largely obsolete! Pretty much everything done here now seems to be automatically handled by FOG after the transition to iPXE 2.0. FOG will now generate it’s own signing keys and seemingly sign the kernels for you, and provides a dedicated boot menu entry to enroll keys via MOK! I’ve yet to test this myself so happy to be corrected if I’m missing anything here.

Additionally, it looks like you can pretty easily migrate existing keys into this setup with some install parameters. I’ll be updating my ansible role to acomodate these changes soon!

[Tom Elliott]

@KMEH This wasn’t somehow. partly it was yours (among all the others) requests for secure boot and some max access to claude that really helped get this more flushed out more properly.

And a lot of mind tossing to get there.

Hopefully you enjoy it and like it (everyone).

[KMEH]

@Tom-Elliott Haha thank you! I was more referring to it slipping past my radar… I’m not sure how I missed it being added to be honest, I’d even read the patchnotes for that version of FOG and missed it.

I’m glad my attempts were able to help get this implemented one way or another. I’m going to update my ansible role as it’s currently broken due to the changes (it manually rebuilt iPXE itself with some files from the FOG repo which have now been removed due to the transition to 2.0 so that no longer works), and then I’ll give it a whirl.

Out of interest, I assume that like the other install time parameters this can be set by the .fogsettings file rather than the command line. I had a look in the docs and I can’t see a matching parameter listed, but I’m not sure if that’s because it isn’t supported or just the docs having not been updated yet.

The role uses templating with the .fogsettings file for the majority of the settings (it’s easier than conditionally setting command line parameters), so I’d much prefer to be able to adjust this from the file if I can!