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

[You-]

I have to say this one has been entertaining, one of the most luddite threads on phoronix.

kind of like "don't look up!".

This feature doesnt change anything about secure boot. It just informs you of the status of what you have. However it is making some people on here feak out.

[erniv2]

I have to say this one has been entertaining, one of the most luddite threads on phoronix.

kind of like "don't look up!".

This feature doesnt change anything about secure boot. It just informs you of the status of what you have. However it is making some people on here feak out.

But i need the green check, else daddy gets angry

[Artim]

This is great!
I would also want support for:

• Secure attention key, i.e. Ctrl+Alt+Del to login.
• Authentication using fingerprint or FIDO/U2F authentication hardware token.
• Authentication via Android device.
• Integration with third-party antivirus software as is done by Windows Security.
• See open ports and firewall configuration.
• Application-based firewall where applications cannot connect out unless allowed.
• Ability to restrict installation of software to only Snap and/or Flatpaks, something similar to Windows S mode.

It can via the "sb-check=false" kernel parameter, but let's hope they remove that so that it cannot be disabled, else it maybe could be disabled by malware.


UEFI Secure Boot is not the end all be of all security, it is not a magic bullet, such thing doesn't exist, it is a layer of security in a multi-layered approach to security. Defense in depth.


With this code being upstreamed, I think it will eventually become standard in all Linux distributions.

One can only hope you're joking with large parts of your comment.

No, there shouldn't be any deep integration with some snake oil security suite. When I want to use a handbrake I'll just use that. And never ever in a million years it should do what Windows Defender does. That is enforcing itself upon the user and turning itself on randomly after you explicitly turned it off. The only relevant reatures that would actually make a difference would be protected folders so not just any app can write to them, and some kind of rudimentary VM to analyze unknown files. But virus detection programs are pretty much snake oil. They can only check signatures, which can be circumvented very easily, and they can use heuristics which just never work. What a great way to teach the user a very false sense of security.

And no, Flatpaks and Snaps are really the last type of packages you want to put your trust into. Instead, you should bring sandboxing to the normal Linux apps. Not to mention that Snaps are the worst pile of garbage, but both systems and AppImages repeat the worst and most unforgivable sin that Microsoft does for decades: Having all apps package every dependency themselves. With a proper system managed by the likes of apt, rpm and co, if there is a critical vulnerability in a dependency like OpenSSL and others that very often have big impact security flaws, you update that one package, and you're good to go. With Windows, Flatpaks, Snaps and AppImages you litteraly have to pray that the application will be updated quickly. But you can't even be sure that it does. Or do you have a way that magically tells you which libraries are used in which version of an app? At least there isn't any user-friendly way.

And no, they should most definitely not remove a way to hide that pile of crap of an "information screen". The large majority of users will, if they ever use secure boot with Linux, use a Microsoft signed shim to do the trick, which is by far the least trustworthy approach. Then you can just turn it off all together, the result would be the same. And no, the majority of users will never enroll their own keys with all the hassle connected to it. Especially given that GNOME isn't just any DE used by only tech-savvy users, but that's mainly used by Ubuntu and Fedora, the two distros that probably are used the most by Linux newbies. They shouldn't be bothered with stuff that wouldn't have much of a benefit but only scare them away because of the amount of work needed. If Linux distributions are able to check all the boxes in a user-friendly way, sure, go ahead and shove it in their faces if things aren't right. But as long as it's connected with way too much trouble or half-assed solutions like kissing Microsoft's ass, just don't show it to newbies. It will only have negative results.

[sinepgib]

I do know how to read (and install my own signing keys as appropriate), but apparently you believe you and other Linux users are not tall enough to ride the (linux) ride and follow instructions to do the work. Perhaps that is true. And they will choose OS platforms more to their understanding.

The point is, and this might surprise you, the mainstream is comprised mostly of people who aren't tall enough to do that work. If you want Linux on the desktop to become relevant at all, you need to streamline stuff for regular people.

[ATFx]

Gnome Developers have always had a Stable Mentality and Judgement Capability....
It would make sense they'd nag their users to enable a security feature that'd break being able to use Gnome,
other Linux related software, let windows off the leash at a firmware level for dual booters.

[qarium]

Let's suppose that on this machine I installed Arch Linux. To boot Arch Linux with Secure Boot enabled, I would need to add my own keys to the firmware, and sign the unified kernel image. So far so good. But then, unless I explicitly remove the Microsoft certificate, somebody can copy the Fedora boot chain (shim + grub + kernel) to my machine, but with a trojaned initramfs, and (because this ancient system doesn't have a TPM and I am forced to use a passphrase - but look, we are talking about Secure Boot, not TPM, here) steal my LUKS passphrase. This is definitely unauthorized.
Just to reword this: for a security-conscious person, any shim signed by Microsoft is malware (because it can boot grub which can boot a properly-signed kernel with an arbitrary trojaned inintramfs).

absolutely right Microsoft is abuse and malware and scam

[patrick1946]

And no, Flatpaks and Snaps are really the last type of packages you want to put your trust into. Instead, you should bring sandboxing to the normal Linux apps. Not to mention that Snaps are the worst pile of garbage, but both systems and AppImages repeat the worst and most unforgivable sin that Microsoft does for decades: Having all apps package every dependency themselves. With a proper system managed by the likes of apt, rpm and co, if there is a critical vulnerability in a dependency like OpenSSL and others that very often have big impact security flaws, you update that one package, and you're good to go. With Windows, Flatpaks, Snaps and AppImages you litteraly have to pray that the application will be updated quickly. But you can't even be sure that it does. Or do you have a way that magically tells you which libraries are used in which version of an app? At least there isn't any user-friendly way.

Flatpak has runtimes and they can be fixed independently. So your OpenSSL can be fixed easily without updating the flatpak package. The advantage of flatpak is that you can have different runtimes at the same time. Something that is not possible with traditional distributions.

And if the original developer will produce the flatpak you will not get same randomly broken package of your distribution because it is tested. As a developer I very often have seen broken packages because the wrong library version was used. Some packagers even patched the original source without any understanding. It would be nice if this FUD of superior packaging of distributions could stop.

[mxan]

It looks like GNOME devs will add the most unimportant features instead of doing something about a certain 18 year old issue.

If you're on about the GTK file picker not having image previews, GNOME are moving away from using that file picker and instead having Nautilus itself provide the file picker, improving the entire experience. https://blogs.gnome.org/christopherd...43-and-beyond/

[bearoso]

The intent is obvious. This is trying to gatekeep legitimacy to those companies that can afford to pay for signing keys. Red hat wants to be the one and only official Linux. Once that's all set up they can fleece users.

Or so the business majors in the company believe. Distros will patch this out, and, failing that, fork if pushed too far. It's not going to get to a point where all operating systems are beheld to corporations. They're deluded. Systemd was of similar intent and invasive, but propagated because the notion wasn't completely hollow. Secure boot is pointless.

[openminded]

No it doesn't, unless the Microsoft certificate is distrusted (and yes that's what I do and that's why I support the recent change of distrusting it by default in the newer laptops). But so far all distributions configure their Secure Boot support packages for easy installation, i.e. for compatibility with the default Microsoft certificate, and make it hard to switch to my own keys.

Two examples:

Let's suppose that on this machine I installed Ubuntu. It boots via Microsoft-signed shim. Fedora does this too. But installing a Fedora kernel on my machine, and booting into it (with Ubuntu userspace still), would be an unauthorized change from my perspective - and Secure Boot with the default keys allows this.

Let's suppose that on this machine I installed Arch Linux. To boot Arch Linux with Secure Boot enabled, I would need to add my own keys to the firmware, and sign the unified kernel image. So far so good. But then, unless I explicitly remove the Microsoft certificate, somebody can copy the Fedora boot chain (shim + grub + kernel) to my machine, but with a trojaned initramfs, and (because this ancient system doesn't have a TPM and I am forced to use a passphrase - but look, we are talking about Secure Boot, not TPM, here) steal my LUKS passphrase. This is definitely unauthorized.

Just to reword this: for a security-conscious person, any shim signed by Microsoft is malware (because it can boot grub which can boot a properly-signed kernel with an arbitrary trojaned inintramfs).

That's why it you really want to do everything right from security POV, you need to sell your old PC and buy one that has TPM.
And that's why it is pointless of Gnome to implement these fancy features before there's a solid and robust approach in major distributions with regard to auto-installing signed unified kernels with TPM-based verifications for keys, hardware and firmware.