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

[sinepgib]

Let me put it this way: Linux Torvalds is a nice guy in comparison. Theo has a permanent pickle up his ass about asking him any questions or getting documentation corrected. He has a toxic personality, which is why most hardware companies using a BSD don't use OpenBSD.

Oh, yeah, I'm not arguing with that. I'm just pointing out that regardless how much of an ass the guy is about introducing changes to the project having it be open source is a good thing. It means, as a side-effect, if he pisses off enough people they can just fork it

[uid313]

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 am not saying it needs to include antivirus software, but I like the concept of having a "Security Center" that no one screen gives an overview and summarizes security properties of the system.

As for sandboxing for normal Linux apps, it's just not happening. There has been decades, and it's just not happening. AppArmor exist, but its not used. SELinux exists, but its not used. seccomp exists, but it's not used. jails only provides security for nerds who manually set it up. Only Flatpak and Snap can bring sandboxing by default to the masses.

By far the most users will use a Microsoft signed shim, so they would never see that "information screen", hence there is no need to have an option to hide it (which could possibly be abused). Nobody should disable UEFI Secure boot, and if they do, they should get a warning.

[Waethorn]

Of course, I thought that much was clear. Coreboot doesn't concern itself with verification or anything other than hardware init and passing control to a payload. The reason I mentioned the other payloads was simply to clarify that Coreboot doesn't care what happens after. You may load whatever you want, as long as your payload is able to. In particular, using Coreboot (with or without TianoCore and with or without enabling SecureBoot on it) does not stop you from using proprietary stuff if you want to, which was the original question.

Well the questions was referring more to whether Coreboot itself would do anything if it loaded Linux directly. Don't one of the Linux PC vendors do this? Like Purism or someone? Or do they have their own signature verification tools?

I thought I read something about them (or it might've been System76) using SeaBIOS though, which is pretty dumb IMO. I mean, if you're going to use a standard firmware interface as a payload, why use anything except a modern UEFI (TianoCore is open source), which is getting more support from software vendors now over legacy BIOS? If a Linux hardware vendor took issue with UEFI control from Microsoft or Secure Boot yadda-yadda, why not just boot directly into their Linux kernel then as a top-to-bottom pieces of integrated hardware and software similar to a Mac, or else use grub or something similar? Why build in firmware layers when you don't have to?

[sinepgib]

I am not saying it needs to include antivirus software, but I like the concept of having a "Security Center" that no one screen gives an overview and summarizes security properties of the system.

I think it wouldn't really be that bad to include an antivirus in the future. Yes, it "just" checks signatures and some heuristics, but even that way it's been massively more effective for Windows than just not having any. We're mostly in the clear because Linux is not popular in the desktop, but if we want it to be we need to be ready for it to be an actual target.

As for sandboxing for normal Linux apps, it's just not happening. There has been decades, and it's just not happening. AppArmor exist, but its not used. SELinux exists, but its not used. seccomp exists, but it's not used. jails only provides security for nerds who manually set it up. Only Flatpak and Snap can bring sandboxing by default to the masses.

Aren't the first three also just for nerds who manually set it up?
Regarding Flatpak and Snap, I don't think those will bring sandboxing to the masses because their cost (because of stuff unrelated to sandboxing) is just too big to assume general adoption. Not everyone has infinite storage and RAM.

By far the most users will use a Microsoft signed shim, so they would never see that "information screen", hence there is no need to have an option to hide it (which could possibly be abused). Nobody should disable UEFI Secure boot, and if they do, they should get a warning.

Some users will see it briefly tho. Some new boards come with 3rd party keys disabled, so they may need to access the UEFI menu before being able to boot without the warning. I don't think it's that much of a problem tho.

[Waethorn]

Oh, yeah, I'm not arguing with that. I'm just pointing out that regardless how much of an ass the guy is about introducing changes to the project having it be open source is a good thing. It means, as a side-effect, if he pisses off enough people they can just fork it

It's ironic that for a project called "OpenBSD", you wouldn't think that the most significant part that's closed would be the lead dev's mind.

[sinepgib]

Well the questions was referring more to whether Coreboot itself would do anything if it loaded Linux directly.

Was it? Then maybe I misunderstood the question.

Don't one of the Linux PC vendors do this? Like Purism or someone? Or do they have their own signature verification tools?

No idea. But Linux itself also supports its own key to verify modules, so if you boot Linux via Coreboot in your ROM (AFAIK it can't boot anything on disk without a payload doing so) you could load verified modules after that. There's no major risk of tampering with whatever's in ROM IMO, so you don't need to sign that part, or at least it's not as critical to do so.

I thought I read something about them (or it might've been System76) using SeaBIOS though, which is pretty dumb IMO.

I agree. Using legacy BIOS is a bad idea if you care about security or flexibility.

If a Linux hardware vendor took issue with UEFI control from Microsoft or Secure Boot yadda-yadda, why not just boot directly into their Linux kernel then as a top-to-bottom pieces of integrated hardware and software similar to a Mac, or else use grub or something similar? Why build in firmware layers when you don't have to?

Well, firmware is harder to update, and you need up-to-date kernels for security. Linux is often used as a temporary payload, making it kexec to another kernel on disk instead I wouldn't recommend using it directly from ROM unless you're doing it for fun. But SeaBIOS in particular sounds rather dumb. If you don't trust UEFI then you could do something like adding signatures to FILO (assuming it doesn't have them, I haven't checked) or using GRUB, as you suggest, but since you're using an open source implementation anyway you could audit it I guess.

[Waethorn]

I think it wouldn't really be that bad to include an antivirus in the future. Yes, it "just" checks signatures and some heuristics, but even that way it's been massively more effective for Windows than just not having any. We're mostly in the clear because Linux is not popular in the desktop, but if we want it to be we need to be ready for it to be an actual target.



Aren't the first three also just for nerds who manually set it up?
Regarding Flatpak and Snap, I don't think those will bring sandboxing to the masses because their cost (because of stuff unrelated to sandboxing) is just too big to assume general adoption. Not everyone has infinite storage and RAM.



Some users will see it briefly tho. Some new boards come with 3rd party keys disabled, so they may need to access the UEFI menu before being able to boot without the warning. I don't think it's that much of a problem tho.

"Security through obscurity" is a false argument. If you move to the country-side, would you not still lock your front door?

You can't sandbox every app with it's own set of dependencies. Thus, you have shared dependencies. Sandboxing an app means the dependencies have to be sandboxed too, otherwise it's not really sandboxed. Right away you're going to have double the storage taken up for regular packaged OS libraries as well as sandboxed dependency versions. The problem is that multiple applications will have different update schedules for the dependencies, so you can end up with many copies of differing versions of the libraries. In Windows without sandboxing, this is known as WinSxS (Windows Side-by-Side, aka "DLL Hell"). This is why I say that sandboxing leads to lazy developers: if a developer builds an application based on whatever set of version dependency packages, and they know that the packages will be sandboxed and the dependency package can be run "forever" because of the sandboxing backwards compatibility, what motivation do they have to move their application to the new set of libraries? Applications invariably need access to data too. What happens when an hacker gets into a system via an out-of-date dependency? They can still destroy data. All the protections in the OS don't mean shit if your userdata goes bye-bye.

When you deal with multiple applications, all with different version controls, you end up with the same as DLL Hell. Maybe not in a stability point of view, but certainly with storage redundancy. It's just like in Windows when you have multiple years of C++ runtimes installed taking up space. Sometimes it's worse in Linux though, since some applications have much heavier requirements for their dependencies, all the way down to which full GUI desktop environment libraries they need (GNOME/GTK or Qt).

Snap is shit. Flatpak handles dependencies a lot better and also handles CSD properly. But they don't address the issues above. What's worse is that because of the FLOSS movement, the most pervasive but worst application around for security - the Web Browser - can't easily have additional components added to it like basic media codecs, hardware acceleration support, or extensions. Much of that has to be baked into the sandboxed package and can't easily be added later like it can with a conventional package on the same read/write filesystem as the rest of the OS. This is why, for example, that Fedora still uses RPM for Firefox on Silverblue instead of using a Flatpak for it.

[sinepgib]

"Security through obscurity" is a false argument. If you move to the country-side, would you not still lock your front door?

How is signing binaries security through obscurity? Security through obscurity refers to hiding the source code in the hope exploits won't be found AFAIK. We know from experience that doesn't work. But you can verify your boot for open source code made with reproducible builds, guaranteeing indeed the source code you see is the binary code you run.
I don't understand the locked doors metaphor, since this is precisely locking your door.

You can't sandbox every app with it's own set of dependencies. Thus, you have shared dependencies. Sandboxing an app means the dependencies have to be sandboxed too, otherwise it's not really sandboxed. Right away you're going to have double the storage taken up for regular packaged OS libraries as well as sandboxed dependency versions. The problem is that multiple applications will have different update schedules for the dependencies, so you can end up with many copies of differing versions of the libraries. In Windows without sandboxing, this is known as WinSxS (Windows Side-by-Side, aka "DLL Hell"). This is why I say that sandboxing leads to lazy developers: if a developer builds an application based on whatever set of version dependency packages, and they know that the packages will be sandboxed and the dependency package can be run "forever" because of the sandboxing backwards compatibility, what motivation do they have to move their application to the new set of libraries? Applications invariably need access to data too. What happens when an hacker gets into a system via an out-of-date dependency? They can still destroy data. All the protections in the OS don't mean shit if your userdata goes bye-bye.

You don't need to sandbox dependencies in a different way. You expose a limited view of the filesystem/network via the kernel itself, meaning the only policies you need will be at the application level: they can call whatever code they want, they'll still see this limited view. I agree sandboxing is not the end of all security measures, but it's just another layer. You don't aim for perfect security because that does not exist. Instead, you aim for making it unpractical, too hard to bother. Sandboxing is about exposing only what the user agrees with the developer is necessary for the application to be useful. Nothing more, nothing less.
The shipping dependencies (DLL hell) has nothing to do with sandboxing, which is why I said Snap and Flatpak's cost is not sandboxing related. That has more to do with the lack of a central authority enforcing userspace libraries compatibility, which means targeting Linux as an end user platform is hard. The lazy solution was to containerize everything. A piss poor one IMO. But that wasn't about security, and we agree in all of its flaws AFAICT.
It may be true that it leads to laziness tho, but IMO that predates these solutions, and this is the mitigation for that fact.

When you deal with multiple applications, all with different version controls, you end up with the same as DLL Hell. Maybe not in a stability point of view, but certainly with storage redundancy. It's just like in Windows when you have multiple years of C++ runtimes installed taking up space. Sometimes it's worse in Linux though, since some applications have much heavier requirements for their dependencies, all the way down to which full GUI desktop environment libraries they need (GNOME/GTK or Qt).

Yep. This is particularly messy in Linux. And there's no way to fix it because of the bazaar model of development. It'll be broken forever. Thus, Snap and Flatpak. I avoid them like the plague, but I can take that luxury because I seldom use anything proprietary.

Snap is shit. Flatpak handles dependencies a lot better and also handles CSD properly. But they don't address the issues above. What's worse is that because of the FLOSS movement, the most pervasive but worst application around for security - the Web Browser - can't easily have additional components added to it like basic media codecs, hardware acceleration support, or extensions. Much of that has to be baked into the sandboxed package and can't easily be added later like it can with a conventional package on the same read/write filesystem as the rest of the OS. This is why, for example, that Fedora still uses RPM for Firefox on Silverblue instead of using a Flatpak for it.

As I said, those issues with containerization are real, but they are orthogonal to sandboxing. For example, you can have regular Firefox sandboxed with Firejail, even if unpractical to use for regular users. I share the dislike for containerization in the desktop (servers are a whole different story, they add much more value in terms of ease of scaling your service by means of adding servers with nearly zero extra effort, compared to the traditional bare metal ways; this also applies to VMs, just more efficiently).

[Waethorn]

Was it? Then maybe I misunderstood the question.



No idea. But Linux itself also supports its own key to verify modules, so if you boot Linux via Coreboot in your ROM (AFAIK it can't boot anything on disk without a payload doing so) you could load verified modules after that. There's no major risk of tampering with whatever's in ROM IMO, so you don't need to sign that part, or at least it's not as critical to do so.



I agree. Using legacy BIOS is a bad idea if you care about security or flexibility.



Well, firmware is harder to update, and you need up-to-date kernels for security. Linux is often used as a temporary payload, making it kexec to another kernel on disk instead I wouldn't recommend using it directly from ROM unless you're doing it for fun. But SeaBIOS in particular sounds rather dumb. If you don't trust UEFI then you could do something like adding signatures to FILO (assuming it doesn't have them, I haven't checked) or using GRUB, as you suggest, but since you're using an open source implementation anyway you could audit it I guess.

Firmware shouldn't be harder to update what with fwupd being available now. If not, they should build in basic disk initialization into coreboot and go back to automatically booting off the "x sector" like they did in the good ol' days. The basic boot "firmware" on a Raspberry Pi is just loaded off disk. Many other ARM chips use U-boot or something custom.

[Waethorn]

How is signing binaries security through obscurity? Security through obscurity refers to hiding the source code in the hope exploits won't be found AFAIK. We know from experience that doesn't work. But you can verify your boot for open source code made with reproducible builds, guaranteeing indeed the source code you see is the binary code you run.
I don't understand the locked doors metaphor, since this is precisely locking your door.



You don't need to sandbox dependencies in a different way. You expose a limited view of the filesystem/network via the kernel itself, meaning the only policies you need will be at the application level: they can call whatever code they want, they'll still see this limited view. I agree sandboxing is not the end of all security measures, but it's just another layer. You don't aim for perfect security because that does not exist. Instead, you aim for making it unpractical, too hard to bother. Sandboxing is about exposing only what the user agrees with the developer is necessary for the application to be useful. Nothing more, nothing less.
The shipping dependencies (DLL hell) has nothing to do with sandboxing, which is why I said Snap and Flatpak's cost is not sandboxing related. That has more to do with the lack of a central authority enforcing userspace libraries compatibility, which means targeting Linux as an end user platform is hard. The lazy solution was to containerize everything. A piss poor one IMO. But that wasn't about security, and we agree in all of its flaws AFAICT.
It may be true that it leads to laziness tho, but IMO that predates these solutions, and this is the mitigation for that fact.



Yep. This is particularly messy in Linux. And there's no way to fix it because of the bazaar model of development. It'll be broken forever. Thus, Snap and Flatpak. I avoid them like the plague, but I can take that luxury because I seldom use anything proprietary.



As I said, those issues with containerization are real, but they are orthogonal to sandboxing. For example, you can have regular Firefox sandboxed with Firejail, even if unpractical to use for regular users. I share the dislike for containerization in the desktop (servers are a whole different story, they add much more value in terms of ease of scaling your service by means of adding servers with nearly zero extra effort, compared to the traditional bare metal ways; this also applies to VMs, just more efficiently).

1) I was mentioning "security through obscurity" because you said Linux is in the clear due to it not being used much. That's not a reason to excuse lapses in security. Being "not a target" isn't the same as being secure. Mac's are more obscure than Windows, but when they get malware, Apple just shrugs and tells you to wipe and reinstall your OS, and to hell with your data because of disk encryption.

2) The majority of application sandboxing technologies don't allow applications access to common OS resources on the flat filesystem, otherwise what's the point? None of them give users control to what level of library resources are permitted by the application because, quite frankly, that's pretty dumb. The best you'd have is a permission system and/or firewall control.

3) The DLL Hell is all about version control of dependencies. When you're dealing with Flatpaks, Snaps, or any other application container system like this, you're going to deal with the same mess, which is what I thought you were getting at when it came to the talk about not having infinite drive space (and there's the RAM concern of multiple versions all running simultaneously).

4) Flatpaks aren't proprietary. Neither are Snaps, but Canonical leverages it for their own interest like they do almost all of their own projects. The rest is made by Debian (well it's mainly by Red Hat employees in most cases).