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?
I consider bootloader attacks a very low-probability threat, and quite honestly I don’t trust the average board vendor to produce anything that’s actually secure anyway. If I were in the habit of carrying a laptop back and forth across international borders I might feel differently, but for a desktop stuck in a room in Canada that hardly anyone enters when I’m not present, Secure Boot is a major hassle in return for a small security gain. So I just don’t bother.
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/
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.
Just because they can do X doesn’t mean you shouldn’t protect against Y.
Just as an example scenario, say border guards took my laptop out of my eyesight. A camera or USB keylogger won’t do anything in that case. Hijacking my bootloader though potentially gives them access to my machine without me having any clue.
Secure Boot is useful and worth setting up. But everyone has to decide their own level of comfort when it comes to security.
You need to correctly set it up tho. ie. remove all default keys because some were discovered ages ago anyway.
They could open up the laptop to insert a small device that reads the usb header. Or just replace the guts of the laptop with something else. Or replace one of the usb leads in your bag with one with a tracker. Or sell a usb-c cable with a tracker for cheap in the gift shop.
There’s a bunch of other ways to compromise your system and some might be easier than putting a backdoored bootloader on your device.
Also, if it’s the TSA, they could almost certainly create a bootloader that was signed by Microsoft to replace any existing one.
Basically xkcd 538 as always.
No point in putting locks on your house, because an attacker can just drive their car through your front door.
The attacks you mention have their own ways of being detected: usually eyeballs. But eyeballs can’t help you against something hiding in your bootloader. So Secure Boot was made.
And I don’t really follow your dual boot claim. If you don’t trust one of the OSes, and you boot it up on your hw, you’re already hosed. At that point it can backdoor your bootloader and compromise your other OS. Secure Boot prevents malicious OSes from being booted, it can’t help you if you willingly boot a malicious OS.
Okay, so my original post I think I was thinking of TPM rather than Secure Boot. TPM would protect against a hostile OS, I think. I think most of my greviences mentioned above are to do with TPM rather than Secure Boot. But they still apply to either.
There are ways to put keyloggers in devices stealthily to where they’re not perceptible to a normal person. For example, they could replace one of the USB leads in your bag with one that transmits keystrokes over bluetooth. If you’re at home, a maid could just plug a keylogger behind your desktop because most people don’t check behind their system when they boot it.
It all feels like a wierd threat model to me. You can either assume that physical access is or isn’t covered by it. If you are worried about physical access (beyond your device being stolen), there is a lot more you need to do to secure it. “It’s better than nothing” isn’t really that convincing to me with regards security models; either you’re protected or you aren’t.
I’m actually not sure what TPM can guard against, but I think you’re right, I think if a malicious OS borked with the bootloader, TPM would catch it and complain before you decrypt the other OS.
Yeah, physical access usually means all bets are off, but you still lock your doors even though a hammer through a window easily circumvents it. Because you don’t know what the attacker is willing to do/capable of. If you only ever check for physical devices, you’ll miss the attack in software, similarly if you only rely on Secure Boot you’ll miss any hardware based attacks. It’s there as a tool to plug one attack vector.
Also, my guess is the most common thing this protects against are stupid employees plugging a USB they found in the parking lot into their PC. If they do it while the OS is running, IT can have a policy that blocks it from taking action. But if they leave it there during a reboot, IT is otherwise helpless.
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.
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 don’t. There’s no replacement when your secure boot configuration is buggy or turned off.
Not everyone cares that someone could alter their bootloader and extract their encryption keys. Others have laptops from shitty companies with known-broken secure boot implementations. If your secure boot can be bypassed because your laptop manufacturer imported “test key do not trust” as their root of trust, there’s nothing you can do to replace secure boot, except for maybe reflashing the firmware to something like Coreboot.
In theory one could write a bootloader that uses something like SGX or some other super privileged system to do hardware attestation before exchanging encryption keys with a server, but I don’t know of anything like that on a bootloader level. Before Intel dropped SGX (SGX being broken completely by side channel attacks like meltdown and spectre), getting Intel to sign your SGX blob was difficult and expensive , so that would bar relatively simple criminals from bypassing your boot configuration, but it’d cost a pretty penny.
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.
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
Is there a phone number I can call to check if I am?
Yes. It is 555-WHOAMI
Just use disk encryption and be done
Disk encryption doesn’t protect against what Secure Boot does. They are very different, often complimentary, systems.
Mandatory read on the subject for the curious (also goes over Secure Boot, Boot Guard etc):
You have to turn off Secure Boot to enable hibernation, and I value hibernation enough to do so.
This is patently false. Secure boot and hibernation are not mutually exclusive.
While I believe you, I haven’t been able to enable hibernation with it on.
It’s a kernel build config. Debian for one ships with support disabled due to security concerns.
So I’d have to rebuild the kernel, not just provide a kernel argument? That’s definitely not a step I’m ready for.
Correct
Not mutually exclusive, but it’s highly probable that if you’re running a mainstream distro, the default kernel is in lockdown mode, preventing hibernation while secure boot is enabled.
On Linux there have been some challenges. Lockdown mode and hibernation don’t play nice. This isn’t to do with secure boot (you can also disable lockdown mode individually) but to prevent kernel access to processes that can edit the hibernation image last-minute (to bypass SELinux, for instance, which shouldn’t be possible even as root), lockdown mode has prevented hibernation for the longest time. I don’t know if it’s been fixed yet, it’s been a while since I last checked.
Disabling secure boot makes the kernel go “whelp, looks like there’s no way to secure the boot process anyway” and will disable lockdown mode by default. If your device is free from other lockdown mode issues, this’ll seem to turn secure boot into a lockdown mode toggle, even though it’s just a side effect.
I believe if your swap partition is on an encrypted LVM, you can still hibernate with kernel lockdown enabled.
This is my setup on debian. Works without any issues.
