GNOME To Warn Users If Secure Boot Disabled, Preparing Other Firmware Security Help

[mirmirmir]

I never thought I would see the day where Linux developers would sheer for Microsoft control over our hardware...

Don't be so dramatic lol, that's cringe

[xcom]

I thought SecureBoot and TPM are M$'s crap. Why show it now?

[mb_q]

Secure Boot is cool but its implementations are nonsense. I've tried enrolling user keys and signing the kernel on a few machines, and the story was the same --- verification was working ok, but a fw reset (removing CMOS battery, proper switch on the motherboard) was enough to jump back to the default SB state with my keys deleted.
So it is either this or using a machine with MS keys baked in, with a MS-approved bootloader blob, not a substantially tempting option.

I suspect the same story applies to all other switches this tool checks; without coreboot one has to trust the firmware, and these are traditionally totally unreliable, most vendors are more concerned with bloating them with kitsch fan animations that moving their quality anywhere higher than "somewhat seems to work for us".

[openminded]

Nice, I hope they'll continue borrowing features from KDE Plasma and maybe one day Gnome will become a usable DE.

[Dar13]

So. Technically, what is this protecting against?

Unauthorized change of kernel? Because it sure doesn't protect any userspace.
Afaiu, there is no problem re-signing a kernel?
So if someone can change your kernel your're screwed either way, privilige-wise.
And if we're talking physical access changes, you're screwed no matter what.

SecureBoot protects against unauthorized changes of the kernel (and if you use a Unified Kernel Image, the initramfs as well). This authorization is done by the platform owner which is usually the owner of the machine, so in the case of your laptop/desktop it would be you.

As far as re-signing the kernel, that depends on how you manage the SecureBoot keys and how the private keys are protected. If you leave the keys on the machine and they are unprotected, without being encrypted with a passphrase or some other mechanism, then yes it's a significantly weaker security enhancement but does still prevent drive-by kernel/initramfs changes.

Physical access is a whole other can of worms, but with firmware integrity features on newer chips (for Intel things like FD0V, BootGuard) the situation is getting better.

The most unfortunate reality of current SecureBoot implementations is that you usually have to keep the Microsoft certificate as a KEK or you may not be able to run certain hardware option ROMs (used for UEFI device drivers, like if you want to network boot,configure hardware RAID, etc) as they are typically signed for the widest compatibility. Sometimes you get vendors who re-sign them to their certificate (I've experienced that with HPE in particular) which isn't much better but it's not Microsoft.

When this lands I'll probably take the time to actually switch over to systemd-boot with a UKI and enable SecureBoot finally. Been coasting for too long with GRUB.

[Weasel]

I never thought I would see the day where Linux developers would sheer for Microsoft control over our hardware...

It's GNOME and Red Hat, what did you expect?

[birdie]

Secure boot in Linux is a security theater anyways because only the kernel image and its modules are signed. Everything else is not, not a single binary or library on the disk.

[Vermilion]

GNOME is used in RHEL in enterprise environments that often force more security requirements than your PC at home.

It's just a warning that could be disabled, stop being so dramatic..

[MorrisS.]

I thought SecureBoot and TPM are M$'s crap. Why show it now?

Indeed, it's a uefi feature provided by hardware producers. Matter is if it useful or not.

[Volta]

Secure boot in Linux is a security theater anyways because only the kernel image and its modules are signed. Everything else is not, not a single binary or library on the disk.

On the other hand 'security' on Windows is non existent. For dozens of years It was revealing user name and password:

https://www.bleepingcomputer.com/news/security/understanding-the-windows-credential-leak-flaw-and-how-to-prevent-it/

2016

This week there has been a lot of news about a flaw in Windows that could be used by web sites to easily gain access to a visitor's Windows login name and password. When I tested this flaw it was downright scary.

Using a test site for this flaw, the site was able to get my test Microsoft Account login name and the hash of its password in a few seconds. Then it took the site less than 30 seconds to crack the password! What is even scarier, is that this flaw is not new and was discovered in March 1997!

Amazing tech!