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

[kylew77]

Theo is an ass. That's the nicest way to say it. If you dealt with him before, you'd know what I'm talking about.

You aren't wrong. A genius but a bit of a dick. I once made a post in the mailing lists that it would be cool if OpenBSD could partner with Lenovo and make a ThinkPad that came with an OpenBSD pre-install option that was certified to run that BSD OS. Much like their T series ThinkPads can come certified to run Ubuntu LTS. He spit all over the idea.

[binarybanana]

I use SecureBoot with my own keys (totally pointless otherwise), but I don't like how they seem to imply that everyone with SecureBoot disabled is running some faulty, broken setup. But hey, that's exactly what I'd expect from GNOME. They know better that you what you need.

Regarding option ROMs, can't you sign them with your own keys, or put their hash in db (signature database)? Assuming a non-crapppy firmware that ought to work.

Most viable Linux malwares out there are designed to achieve persistence via installing kernel modules.

Joke's on you, my kernel has no module support at all.

[jacob]

Still waiting to see someone influential raise a demand for consortium consisting of major OS and hardware vendors that grants keys instead of leaving all control to microsoft

That ship has unfortunately sailed but on ARM-based platforms, Linaro or ARM itself should be the one who issues the keys

[patrick1946]

That was just one example. I very much doubt that there's a shared runtime for every dependency possible.

No but for all important. So the chance that many applications will share a faulty implementation is very low. And you cannot only have bugs in libraries but in the application itself. But because you don't have any versions dependencies in flatpak you always have the newest application version. Something which is seldom the case in traditional package systems. And this packages are hopefully build the library version they are designed to not a random version which the distributor chooses.

Many packager don't understand that even if you are ABI compatible it doesn't mean that you are behavior compatible. As a developer I can tell you that this matters.

https://www.hyrumslaw.com/

In a ideal world the packages a provided and tested by the developers. And flatpak makes that much easier!

[Artim]

I agree to your response. It should have no "tie-in" with Android, which is a spyware hole for Google, nor third-party software. It should stand on it's own except it should have chains of trust down to the firmware on that specific computer without relying on additional hardware. If that means certificates, so be it. If you don't like it (not directed at you, specifically), come up with a better idea. Linux always advocates "if you don't like it, here's the source code - changes it how you like it". If it pisses people off that they don't like how something works, but aren't willing to learn how to change it, then that's their problem.

The "application-based firewall" is an interesting concept that's been done before (think Sculpt OS or Tails). However, it's executed in a way that is user-hostile and won't attract any third-party application developers.

Sandboxing is an idea that works in concept, but fails in practice. An application that is given access to data stores can easily corrupt it, even if the OS is protected from modification. The dependency issues are far from resolved, since there is little to no end-user notification regarding outdated versioning of dependency packages. Dependency versioning is at the mercy of the sandboxed application package. It's often used as a crutch for lazy app developers.

Well I can't agree with you either. The "tie-in" with Android (and any other OS, but mainly Android and iOS) should be in a way that makes use of their TPM implementation. And I never said I have anything against certificates. But never in a million years should a company as incompetent and all-overbearing as Microsoft should have any say in that matter. If it needs to be trusted by third-parties, it should be in the same way other certificates like for encrypted communications do it: there should be several independent roots of trust. Of course then there's the same problems with it too: there needs to be a way of telling the device to distrust a chain of trust if someone abuses their power or simply has bad security so everyone can create a certificate for everyone. This would be very difficult to pull off in a setup, but in most cases it would probably be enough to have the user connect to their WiFi first. But what if a chain of trust is distrusted at some point after installation?

Also, if it's done with user creates certificates as many distributions would need to do currently if the user wanted it to use secure boot, it needs to be a user-friendly, automated yet transparent method that wouldn't scare everyone off but the most tech-savvy users.

And of course sandboxing isn't the end all be all solution either. It's more like why should applications in the 2020s not all be sandboxed with runtime permissions granted by the user when needed, like iOS and Android do it for years now? It would be the same argument as with SSL/TLS encryption of all network traffic. Sure, there are always terrible vulnerabilities or conceptual weaknesses that would allow an attacker to decrypt the data in some MITM-Attack, but it still would be quite the added level of difficulty to do so. So nobody in their right mind (and no, all the politicians lobbying against (end-to-end-)encryption aren't) would say anything against having all network traffic secured with at least TLS 1.2 and ephemeral encryption keys.

Of course, no packaging system is perfect, But I'd rather see a system like the one Debian-based distributions use, to be upgraded in a way that more dependencies can be present in multiple versions that still receive security updates, that are always sandboxed and are more distribution independent, rather than having to deal with foul compromises of the likes of AppImages, Snaps and Flatpaks.

[Artim]

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.

That was just one example. I very much doubt that there's a shared runtime for every dependency possible.

[STiAT]

I don't know, telling everyone around by default that I have disabled SecureBoot would not be what I want. I hope the setting disables this for gnome and plymouth.

Though, I probably will give in at some point in time, I think the security it provides is marginal at best for the hassle it is.

[Waethorn]

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.

I agree to your response. It should have no "tie-in" with Android, which is a spyware hole for Google, nor third-party software. It should stand on it's own except it should have chains of trust down to the firmware on that specific computer without relying on additional hardware. If that means certificates, so be it. If you don't like it (not directed at you, specifically), come up with a better idea. Linux always advocates "if you don't like it, here's the source code - changes it how you like it". If it pisses people off that they don't like how something works, but aren't willing to learn how to change it, then that's their problem.

The "application-based firewall" is an interesting concept that's been done before (think Sculpt OS or Tails). However, it's executed in a way that is user-hostile and won't attract any third-party application developers.

Sandboxing is an idea that works in concept, but fails in practise. An application that is given access to data stores can easily corrupt it, even if the OS is protected from modification. The dependency issues are far from resolved since there is little to no end-user notification regarding outdated versioning of dependency packages. Dependancy versioning is at the mercy of the sandboxed application package. It's often used as a crutch for lazy app developers.

[Waethorn]

Yup exactly, the core principles behind SecureBoot and TPM are actually quite sound its just the implementation is absolute s**t. I think this is more of a result of crappy software that motherboard makers produce rather than Microsoft specifically (obviously the BIOS will have Microsoft keys as default and there isn't really such a thing as a "linux key" unless its a shim at which point SecureBoot is kinda pointless).

Most motherboard makers don't write the firmware code. AMI and Phoenix do. Motherboard companies just tell them which setting options to include and give them copies of logos and graphics.

[Waethorn]

Yes, that's why all those millions of compromised desktop boxes in the massive botnet swarms are always Linux systems.

Oh wait, no - they are all Windows boxes. How odd.

Don't be facetious. There are lots of Linux systems that get compromised too - but those are servers. You'd think they'd be more secure than they are.