FOG Secure Boot with Shim
-
@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!
-
@KMEH This might be able to help:
https://docs.fogproject.org/en/latest/management/server/install-fogsettings/ -
@Tom-Elliott Ah yes, thanks. That’s what I was looking for. I was checking on that page but I couldn’t find it, even did a ctrl+f for secure boot. I wonder if it was an old cache or something, weird!
-
@Tom-Elliott Just a thought, was reading through the docs and I noticed that because of the adhereance to stock iPXE 2.0 netbooting with HTTPS is disabled by default. This may be a little too complicated so I’d get avoiding this, but you could probably work around this by nesting shim and iPXE to boot a custom signed iPXE. It would work something like this:
- Netboot iPXE 2.0 normally with it’s shim
- Use autoexec.ipxe with the shim command to reload that shim
- Using autoexec.ipxe chainload a custom build of iPXE 2.0 that has the FOG certificate bundled and trusted.
If the binary chained isn’t already trusted, I believe you should be able to use some scripting to then automatically chain in mokmanager or fallback to chaining via http.
Provided you use the normal FOG signing keys, this should work fine, though it does mean having two shims. It may be worth it to close that small gap in HTTPS. Both the shim and custom iPXE could be chain loaded via TFTP. It does add a little more complexity to the signing and boot process but I figured it was worth mentioning, as having HTTPS wherever possible does seem valuable.
-
Using “secureboot/snponly-shimx64.efi” without secureboot works like snponly.efi ?
Could it be possible to add a very lightweight OS such as Tiny Core Linux with enrolment kit inside (or that get it from web link) that would enrol key automatically via pxe menu ?
-
@jmeyer I’m confused what you’re asking?
secureboot/snponly-shimx64.efi simple is the shim that agrees with the signed snponly.efi. This agreement is only required during “Secure Boot Enabled”, but would/should still work if used for booting “secure boot disabled”.
We already have an ability to boot to the mok manager from the iPXE menu, as well as loading into FOS as its own specific task.
-
@Tom-Elliott
I think something isn’t working for me.
I can’t get iPXE menu when secureboot is enable and secureboot/snponly-shimx64.efi is set.
I have :NBP filename is secureboot/snponly-shimx64.efi NBP filesize... Downloading NBP file...Then I go back to Boot Menu.
I thought is could be network card drive or something like this but it’s loading fine without secureboot enable.
