0) Threat model (why this matters)
If an attacker can edit the GRUB menu or inject parameters via PXE/provisioning, they can poke early-boot code paths (like IOMMU parsing). We:
-
lock GRUB; 2) enforce Secure Boot + kernel lockdown; 3) lock provisioning paths; 4) remove alternate boot vectors.
1) Enable & verify Secure Boot (+ Lockdown)
Check status (any distro):
If disabled: enable in firmware (UEFI Setup) → “Secure Boot: Enabled”.
Custom modules: if you use DKMS/custom drivers, sign them or use a Unified Kernel Image (UKI) workflow; avoid enrolling overly broad MOKs.
Optional stricter lockdown: add lockdown=confidentiality to your kernel cmdline (once GRUB is password-protected).
2) Protect GRUB (set superuser + hashed password)
Generate a PBKDF2 hash:
Add a GRUB superuser (GRUB2):
Require auth to edit/select entries: (Ubuntu/Debian)
RHEL/Alma/SUSE (GRUB cfg regeneration):
Use when you need the menu:
Tip: Keep a sealed, offline copy of the hash and a break-glass bootable USB.
3) Lock file permissions & restrict boot devices
4) Disable kexec (no in-OS kernel swapping)
5) Harden PXE / provisioning (if used)
-
Disable PXE where not required; otherwise:
-
Use UEFI Secure Boot-signed iPXE or vendor-signed boot loaders only.
-
Serve boot artifacts over HTTPS with certificate pinning; avoid unauthenticated TFTP.
-
Isolate provisioning on a dedicated VLAN, DHCP-scoped to known MACs.
-
Store kernel/initrd on a read-only web root with CI-signed artifacts.
-
Require change-control to modify kernel parameters in your provisioning templates.
-
6) Baseline & monitor
7) Recovery plan (don’t lock yourself out)
-
Keep UEFI admin password in a sealed secret manager (two-person rule).
-
Maintain a signed rescue image (USB) you can boot when GRUB is protected.
-
Document the grubadmin password reset workflow.
Drop-in repo file
Add this to your repo as HARDENING.md, and include a helper script:
scripts/grub_harden.sh
