Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux and Secure Boot certificate expiration

lwn.net

Post reply on HN
Print view View original

71–80 of 272 posts

Re: Linux and Secure Boot certificate expiration

#71

Post by ACCount36 »

flexagoon wrote: post #66
ACCount36 wrote: post #49

Earlier quoted context omitted.

Who controls the fucking certs? "My computer was compromised with an early boot stage hypervisor backdoor" happens basically never. It's an attack vector that exists almost entirely in the minds of infosec fucktards. "My brand new device ships with vendor-selected boot certificates that can't be changed, can't be overridden, and control what software I can install onto my own device" happens with every other smartpho…

> Who controls the fucking certs? Cert authorities, just like in case of SSL. Is SSL also an evil technology designed to take away freedom from the internet? > vendor-selected boot certificates that can't be changed That's a lie. Certain drivers are signed with a specific key, and they can only be used when this key is installed, which makes sense. The same thing happens with SSL - if you remove pre-installed CA cert…

Take an iPhone or a Switch. Then disable Secure Boot on it. Good fucking luck.

The reason why Apple or Nintendo go out of their way to make this impossible isn't user security. It's the "security" of their 30% App Store cut.

Out in the wild, Secure Boot exists to "secure" vendor revenue streams - and PCs are the only devices where it's even possible for the user to disable it. Most of the time.

What's happening in smartphone space is enough of a reason to treat Secure Boot on PC like an ongoing attack. The only reason why there are still legitimate ways to disable or adjust it is that most PC manufacturers don't have their own app store.

Re: Linux and Secure Boot certificate expiration

#72

Post by flexagoon »

porridgeraisin wrote: post #43

Secure boot, disk encryption, etc are more trouble than they are worth IME. I have them all off. Qualifier: for personal computers that you don't take regular backups of, test backups, etc

Secure Boot's benefits are definitely not as strong (I don't think flashing custom backdoored firmware is a common attack vector for personal computers), but FDE is still useful in case your laptop gets stolen, because thieves looking for sensitive data on a hard drive is a thing that does actually happen.

I also wouldn't really say it's much trouble. If you have a TPM and use systemd, you can set it up to unlock FDE automatically on boot, otherwise, you just have to input an extra password when turning on your machine.

Re: Linux and Secure Boot certificate expiration

#73

Post by blkhawk »

jeroenhd wrote: post #56
pdimitar wrote: post #46

Earlier quoted context omitted.

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?

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 no…

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.

Re: Linux and Secure Boot certificate expiration

#74

Post by zozbot234 »

froh wrote: post #44
ACCount36 wrote: post #33

Earlier quoted context omitted.

Secure Boot is the computing antichrist, and Linux folk were 100% right to rally against it. As well as a whole bunch of other "Trusted Computing" garbage.

mind to elaborate? I'd love to know if my machine has been compromised with early boot stage "meta-hypervisor" or not. the promise of secure boot and trusted computing is backdoor-free boot. what is in your eyes evil and garbage about that?

> I'd love to know if my machine has been compromised with early boot stage "meta-hypervisor" or not.

Boot from read-only media you control, or set up network boot from a source you trust - you have to trust the firmware anyway. Secure Boot itself is quite pointless.

Re: Linux and Secure Boot certificate expiration

#75

Post by eqvinox »

> Linux users who have Secure Boot enabled on their systems knowingly or unknowingly rely on a key from Microsoft that is set to expire in September.

No I don't because I installed my own keys, and so should you, and can we please stop assuming that Secure Boot means Microsoft keys?

Re: Linux and Secure Boot certificate expiration

#76

Post by vbezhenar »

palata wrote: post #55

[Warning: I'm not interested in sarcasm or uninformed rants against secure boot, there are plenty already] I'm hoping to get insights from people who understand secure boot well here. My understanding on Android (for the minority of Android manufacturers that do it correctly) is that there is a "manufacturer key" burnt somewhere on the ROM that cannot ever be changed, and once a first system is installed properly: 1.…

Of course it is possible to use custom keys. At least it was possible on all EFI computers I owned. There are no "manufacturer keys". There's usually an option in BIOS to restore default configuration which resets to MS keys, but you can delete all MS keys.

Now there might be further complications, for example some Lenovo laptops using firmware blobs signed by MS keys and if you delete MS keys, you might brick your laptop, because GPU won't start anymore. That said, I'm using Lenovo Thinkpad T14s Gen4 Intel right now with all keys deleted and my custom key added and it works just fine. May be it's AMD issue.

Re: Linux and Secure Boot certificate expiration

#77

Post by palata »

jeroenhd wrote: post #60
palata wrote: post #55

[Warning: I'm not interested in sarcasm or uninformed rants against secure boot, there are plenty already] I'm hoping to get insights from people who understand secure boot well here. My understanding on Android (for the minority of Android manufacturers that do it correctly) is that there is a "manufacturer key" burnt somewhere on the ROM that cannot ever be changed, and once a first system is installed properly: 1.…

> Still on Android, it's possible to add custom keys. That's what GrapheneOS and the likes use. AFAIK, that depends on the hardware used. Google Pixels allow it, but it's not universally permitted. Plenty of stories can be found on XDA where people tried to lock their bootloader that bricked their phone.

> AFAIK, that depends on the hardware used. Google Pixels allow it, but it's not universally permitted.

You're right! That's what I mentioned the few manufacturers who do it correctly. GrapheneOS only supports Pixels for other reasons than that. CalyxOS supports other devices (one constraint being to be able to relock the bootloader). /e/OS doesn't seem care so much about the secure boot.

> Plenty of stories can be found on XDA where people tried to lock their bootloader that bricked their phone.

That raises a question: what is the point of relocking the bootloader? If overwriting the keys means that the whole system will be formatted, then I don't see why it should ever be prevented at all? If an evil maid wants me to lose my data, they can leave with the laptop, right?

Re: Linux and Secure Boot certificate expiration

#78

Post by zozbot234 »

flexagoon wrote: post #66
ACCount36 wrote: post #49

Earlier quoted context omitted.

Who controls the fucking certs? "My computer was compromised with an early boot stage hypervisor backdoor" happens basically never. It's an attack vector that exists almost entirely in the minds of infosec fucktards. "My brand new device ships with vendor-selected boot certificates that can't be changed, can't be overridden, and control what software I can install onto my own device" happens with every other smartpho…

> Who controls the fucking certs? Cert authorities, just like in case of SSL. Is SSL also an evil technology designed to take away freedom from the internet? > vendor-selected boot certificates that can't be changed That's a lie. Certain drivers are signed with a specific key, and they can only be used when this key is installed, which makes sense. The same thing happens with SSL - if you remove pre-installed CA cert…

> Which is exactly why users have the freedom and choice to just disable Secure Boot?

There's some x86 hardware in the wild where the option to disable Secure Boot does not work. Which is part of the reason why Shim exists in the first place - it allows you to boot unsigned code with the machine owner's consent, even with Secure Boot enabled.

Re: Linux and Secure Boot certificate expiration

#79

Post by eqvinox »

omnibrain wrote: post #28

I'm sure this is a naive take, but why is it not possible to enter a new key into the BIOS (dating myself, I know it's EFI) by hand?

It's possible and it's what you should be doing. "sbctl" (https://github.com/Foxboron/sbctl) AFAIK has a reasonable frontend for doing that on Linux (don't know, I did it manually). You have to put the system in "secure boot setup mode" in BIOS/UEFI options before booting, which enables changing the PK (Platform Key) which is used to chain off all the other keys. (Setup mode should be automatically exited when you install a new PK.)

You can keep the Microsoft keys in there if you want to dual boot Windows, you just need to re-sign the keys themselves with your own PK.

Re: Linux and Secure Boot certificate expiration

#80

Post by vbezhenar »

saidinesh5 wrote: post #4

Just out of curiosity, how good is the secure boot experience these days? I've had to disable it on all my installations because of either nvidia drivers or virtual box modules. In general Arch based distros didn't seem too friendly for secure boot set up.

I'm using Arch and it was very easy to configure secure boot. I don't know why you think it's not friendly. I'm using UKI, so no bootloader at all, my UKI is signed by my own key which is installed into UEFI. Most of sign process is handled by systemd, so most of it is already integrated into the base system.
Post reply on HN