[blkhawk]

Secure boot belongs to a class of security that while clearly giving a theoretical benefit in practice it falls far short of providing any benefit whatsoever at least to the user of a system. Its introduction was mostly part of a wider (probably partially defunct and failed regarding mobile x86) strategy to lock down the PC so the Microsoft store and purchased apps through it would be more secure from the end-user. Secondary was in my opinion better security for handheld phones and tablets running x86 but there the "App store" aspect is even more clear.

"attacker tampers with your system" does not happen at least in the way you think it does or it does not protect you against meaningful attack at all.

[pdimitar]

What kinds of attacks was Secure Boot designed to mitigate? Is it the evil maid attack? Or an accidentally ran with `sudo` program can indeed screw your entire boot process and inject rootkits etc.? Or is it something else?

[cesarb]

> What kinds of attacks was Secure Boot designed to mitigate?

Boot sector viruses, or their modern equivalents. Basically, anything which injects itself into the boot chain before the antivirus can start; after that point, the antivirus is supposed to be able to stop any malware. That is, they wanted to prevent malware from being able to hide from the antivirus by loading before it.

[danudey]

Another example: a custom kernel build or kernel module that backdoors your system or steals data at the kernel level. Secure boot provides the opportunity for a chain of trust that goes from the firmware manufacturer all the way down to your individual kernel modules.

The firmware validates the shim. The shim validates the boot loader. The boot loader validates the kernel. The kernel validates the kernel modules.

Once you have that chain of trust, you can also add in other factors; encrypt your disk using a key, seal the key in the TPM, and lock that key behind validation of the firmware and the boot loader. Your system boots, those different components are measured into the PCRs, and if the combination is correct the key is released and your disk can be decrypted automatically. Now if someone boots your system using a different firmware or boot loader, the TPM won't release the key, and your disk can't be decrypted except by someone with the passphrase, recovery key, etc.

Without secure boot, you can't trust that any of those components aren't reporting falsified measurements to the PCRs, lying to the TPM, and getting access to the key to decyrpt your disk despite booting from a compromised USB drive. That, of course, means you can just encrypt your disk using only a passphrase that you manually enter, but for a lot of users (sadly) that's too complex and they'll choose not to use disk encryption at all.

Case in point, TouchID and FaceID are seen as alternatives to using a PIN or passphrase to unlock your iPhone, but they're actually meant as alternatives to not locking your phone at all - a way to make device security transparent enough that everyone will use it. Without a secure chain of trust from the firmware to the kernel, that's not really an option.

[jeroenhd]

Evil maid and rootkits, mostly. It's also part of the trust chain that unlocks an encrypted disk without having to enter a password.

On Windows, secure boot has worked pretty well when it comes to rootkits. MBR rootkits were trivial to write, but UEFI rootkits require UEFI firmware changes or exploiting the bootloader process itself, both of which are much more complex. If malware uses the Linux shim, the TPM will notice and refuse to provide the Bitlocker key, so your computer won't boot without going to the IT office and asking for the recovery key (which should prompt more investigation).

[blkhawk]

That is sorta the rub - the treat profile "evil maid" is mainly governmental actors for most people even for Orgs. Your example shows mostly how an org can secure their own devices against casual misuse by unprivileged users. This does not help against any serious attack. It only protects against stuff you don't need to worry about generally.

[magicalhippo]

> Or an accidentally ran with `sudo` program can indeed screw your entire boot process and inject rootkits etc.?

The more realistic scenario would be exploiting a privilege escalation bug. Of which there have been and will be plenty of on both Windows and Linux.

[msgodel]

Anything that locks you out of your own computer is at absolute best an availability failure but more often than not forces you to use compromised system software.