So basically, my setup has everything encrypted except /boot/efi. This means that /boot/grub is encrypted, along with my kernels.
I am now attempting to get secure boot setup, to lock some stuff, down, but I encountered this issue: https://bbs.archlinux.org/viewtopic.php?id=282076
Now I could sign the font files… but I don’t want to. Font files and grub config are located under /boot/grub, and therefore encrypted. An attacker doing something like removing my hard drive would not be able to modify them.
I don’t want to go through the effort of encrypting font files, does anyone know if there is a version of grub that doesn’t do this?
Actually, preferably, I would like a version of grub that doesn’t verify ANYTHING. Since everything but grub’s efi file is encrypted, it would be so much simpler to only do secure boot for that.
And yes, I do understand there are security benefits to being able to prevent an attacker that has gained some level of running access to do something like replacing your kernel. But I’m less concerned about that vector of attack, I would simply like to make it so that my laptops aren’t affected by evil maid attacks, without losing benefits from timeshift or whatnot.
I found the specific commit where grub enforces verification of font files: https://github.com/rhboot/grub2/commit/539662956ad787fffa662720a67c98c217d78128
But I don’t really feel interested in creating and maintaining my own fork of grub, and I am wondering if someone has already done that.
If you don’t know, then why don’t you shut up, yeah? I’ve spent 3 weeks researching this, even going as far to read the source of grub. Don’t just assume you’re right without doing any research.
I have the time now. Classes are just getting started. But I’ll be busier in the future. Due to the way that arch is setup, this is easier than signing everything, plus I get instant restores.
And it’s not a bug. It’s intended behavior for systems like high value servers where security is valued over all else, to prevent privilege escalation by an attacker exploiting a kernel bug to load more kernel modules or taking advantage of a similar exploit. But for my desktop system, such an attack is not in my threat model.