How do you secure your bootloader without secure boot or why doesn't it matter?
How do you secure your bootloader without secure boot or why doesn't it matter?
I've made the effort to secure mine and am aware of how the trusted protection module works with keys, Fedora's Anaconda system, the shim, etc. I've seen where some here have mentioned they do not care or enable secure boot. Out of open minded curiosity for questioning my biases, I would like to know if there is anything I've overlooked or never heard of. Are you hashing and reflashing with a CH341/Rπ/etc, or is there some other strategy like super serious network isolation?
Very recent relevant article, apparently not mentioned yet https://arstechnica.com/security/2024/07/secure-boot-is-completely-compromised-on-200-models-from-5-big-device-makers/
At the point where the feds are paying Israelis millions to break your boot shit, they're paying dudes to watch you type in your password or any number of other things. I'd argue as long as you're not among the [number of prey] the predators are looking to take down at the back, for whatever category of shit you're in, you're fine
And if you are?
Disconnect
Now I'm not very smart, but I see no purpose of it, so I just turn it off so it doesn't fuck with my ability to boot.
You can use measured boot as part of the firmware boot process, store a hash of the known good boot files on a trusted media and compare that.
This is done with the Heads payload in Coreboot. But support is like only Thinkpads and now also soon Novacustom, Nitrokey and maybe System76 laptops.
The thing is, then you know your kernel is safe, but what about the rest? Depending on the attack vector, a system like on Android with full immutability and a recovery that verified the whole OS root partition would be safer.
But this means that you have no ability to customize, without breaking things.
I have my home folder encrypted and I enter my password on boot. I'm not really sure what benefits Secure Boot has in environments where you have to enter your password anyway. And in environments where you don't have to enter your password, someone could just steal your system anyway and boot it to get your data.
Secureboot is meant to help protect you against the evil maid attack. IE someone with physical access to your computer can compromise your boot loader with a keylogger that can capture your encryption password so that when they return they can gain access to your computer as they now know your password. Though the vast majority of people just don't need to worry about that level of attack so I have never really bothered with secureboot.
The thing is... If someone has access to your system enough to replace your bootloader, they could probably just slip a USB keylogger between your keyboard and computer. Or set up a small hidden camera. Or plug all your devices into a raspberry pi to spoof the login screen.
It strikes me as odd that people assume that an attacker with a few hours physical access is going to bother going down the "change the bootloader" route when there are other, easier routes available.
Ironically, the only practical use case I can see for Secure Boot is when you have a dual boot setup where you don't trust one of the OSes. Which I'm betting wasn't Microsoft's intention at all.
Keep EFI bootloader off the computer (n+1 copies on a flash drive). Make
/bootpartition fully encrypted.Don't trust Secure Boot.
If you can, try the coreboot.
Don't trust Secure Boot.
That's the second best thing as long as you don't worry about nation state actors (you're fucked by then anyway). Only requirement is a board/laptop manufacturer with a proper uefi setup (eg ability to set your own keys, not using those "do not use" test keys, etc) - that usually comes with business machines.
You have to turn off Secure Boot to enable hibernation, and I value hibernation enough to do so.
I believe if your swap partition is on an encrypted LVM, you can still hibernate with kernel lockdown enabled.
This is patently false. Secure boot and hibernation are not mutually exclusive.