Secureboot issues
-
If this is solved, I give the developers a beer.
-
@bgbgbgbg There is money und time involved to make this work. Check out the information on the iPXE website:
https://ipxe.org/appnote/etoken
and
http://forum.ipxe.org/showthread.php?tid=7533Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)
Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG
-
@Sebastian-Roth said in Secureboot issues:
@bgbgbgbg There is money und time involved to make this work. Check out the information on the iPXE website:
https://ipxe.org/appnote/etokenThe best part of that article I found was the footnote “Microsoft is special”
Not only does iPXE need to be signed, but the FOG Project would have to go through the same process MS boot image signing for each FOS Linux kernel that was released. This would most assuredly impact the “free-ness” and responsiveness to changing hardware demands for FOG imaging.
-
I hope Microsoft has to be friendly and kind-hearted, because they want to continue to sell their licenses. If you can not easily deploy - much like we do in schools and universities - you will switch to Linux, especially with such simple systems with data storage and LibreOffice and Internet access, for example. Microsoft certainly wants to prevent that.
Ask MS and say that you need it for free. FOG Project is no longer a small by-product.
-
@Deimos said in Secureboot issues:
Ask MS and say that you need it for free. FOG Project is no longer a small by-product.
Do you have good contact with someone working in the right position at Microsoft? If so then you may ask her/him… I am not going to spend any time or money on this unless I see people from the FOG community pushing this.
-
It would be nice to have, but definitely not make or break for our environment. We already have to touch so many things in BIOS to set our machines up the way we want them that turning off secure boot is just one of many. I don’t really see the value. I know its sold to protect from rootkits, but it feels more like vendor lock-in to Windows.
-
@astrugatch
Please do not forget that after deactivating also the reactivation means further steps. And that with 500 devices within a week! -
Isn’t that what command and configure is for (if you’re a dell shop at least)?
-
@astrugatch said in Secureboot issues:
Isn’t that what command and configure is for (if you’re a dell shop at least)?
Yes, we use command and configure (CCTK) to set default bios settings. I started looking into building cctk into FOS Linux so those bios settings could be made via a post install script. I think that project fell off the table a while ago.
-
I would be very interested in that. Do you have a GIT for that, that I could look at?
-
@astrugatch It never made it to the repo. It was a skunkworks project I was working on. I just went and grabbed the centos version of cctk https://downloads.dell.com/FOLDER05519675M/1/command-configure-4.2.0-553.el7.x86_64.tar.gz to see if I could rebuild the test environment.
-
Hi all, i have secureboot working with ipxe (FOG) using a self-signed certificate and you do however need to enroll the keys but i have added an .efi program that you can run to automate all this from the pxe boot menu to ease this process.
i’ve been testing it for the last 12 months or so to see if there is any gotchas but none yet and over 80% of our estate have secureboot with ipxe working (7K devices) - only lenovo x1 carbons have been problematic but this appears to be due to poor bios and/or secureboot implementation.
this does mean you have to manage the certificates yourself going forward too as you are essentially taking ownership and provisioning the devices and applying your own PK which means you have to trust 3rd party CAs however the plus side there is no cost involved. i also don’t have assurances how to remotely distribute a renewed certificate when it expires but expiration is 10 years and there is going to be some work needed when microsoft CA expires in 2026.
on first attempt, i hadn’t included microsoft CA so windows os failed to load with untrusted error from secureboot… i loved the irony… i dont trust microsoft either
if anyone is interested i can write up instructions however you have to remember technically this is outside of FOG remit, so support on FOG forums will be extremely limited and unfortunately with 2 jobs i have very little time to spare either.
-
@lee-rowlett I am very interested; anyone else wants to see a writeup?
-
@lee-rowlett I would be very interested to see how this could be achieved. I have 1000 Lenovo devices and I would prefer to not have secure boot reconfigured on all machines…
-
@lee-rowlett Hi, Where is your “howto” ?
-
@lee-rowlett very interested, maybe i can do something if you can send me the information…
-
unfortunately i do not have time to write up in detail step by step instructions but this is how i’ve done it:
follow this brilliant guide:
https://www.rodsbooks.com/efi-bootloaders/controlling-sb.htmlincluding “Securing Multiple Computers” section, once you’ve generated the “LockDown.efi”
copy LockDown.efi to ipxe folder on fog server (i’ve renamed mine to EnrollKeys.efi) then add the option to PXE Menu.
then sign your init, bzimage and any other bzimage version you may use with your new cert you’ve generated above - something like this:
cd /var/www/html/fog/service/ipxe mv bzImage bzImage-unsigned sbsign --key /etc/efikeys/DB.key --cert /etc/efikeys/DB.crt --output bzImage bzImage-unsigned mv bzImage32 bzImage32-unsigned sbsign --key /etc/efikeys/DB.key --cert /etc/efikeys/DB.crt --output bzImage32 bzImage32-unsigned mv bzImage41713m bzImage41713m-unsigned sbsign --key /etc/efikeys/DB.key --cert /etc/efikeys/DB.crt --output bzImage41713m bzImage41713m-unsignedjust remember to re-sign any init/bzimage when upgrading kernel/fog.
so the process is when you get a new machine put secureboot into user/setup mode then boot to pxe and run “Enroll Keys” option on pxe menu which will set secureboot keys accordingly, the beauty of this is you will also only need to do this once on a machine and then you will have secureboot on working with fog, when you come to reimage that same machine secureboot will already be setup.
the only caveat i would say is i don’t know what the behaviour is going to be when the Microsoft UEFI CA expires in 2026 - as you’re now effectively managing your own secureboot keys - you will need to update and manage the CAs in the db. this would normally be managed by microsoft updates/OEMs i assume.
-
