As far as having a GUI front-end to allow a user to manually change the kernel command line before booting, because it’s a one-off change that doesn’t persist reboots, I suppose (like with our failsafe boot mode in the boot menu) it could be done safely.
It would still need someone willing to write the feature though
Correct, because it’s not a persistent change (which is what Heads cares about), someone booting your system or existing to the recovery shell will not trigger a warning as the system wasn’t actually successfully tampered with in those cases.
Off the top of my head, I suppose you could challenge the user to enter a password to get access to the recovery shell, and if they fail too many times, remove a signed kexec config files in /boot so that the real user gets an alert when they boot next.
Thanks for the answer. I’ll think some more about it and maybe sometimes look into the coreboot code.
Anyway I’d prefer to change a signed file in a way that it could not be restored from the rescue shell - thinking about it: if someone took the notebook apart and copied the file from /boot beforehand she or he could use the rescue shell and cover their traces.
Isn’t there something that could be altered that would affect the initial value of a relevant PCR?
The “nuclear option” would be to erase the TPM. That’s something an attacker couldn’t restore (as they don’t know the shared secret inside the TPM).
This option has other implications though, as some Heads users also store part of their LUKS unlock key in the TPM–it gets combined with a passphrase they type in at boot so that one can only unlock the OS if the TPM has proper measurements.