Secure Boot probably not as secure as users would prefer

stargate-sg1-cheyenne-mtn · 2024-07-26 07:53:55

Secure Boot probably not as secure as users would prefer:

https://arstechnica.com/security/2024/07/secure-boot-is-completely-compromised-on-200-models-from-5-big-device-makers/

reminded of a Bruce Schneier commentary/interview from 2012:

https://www.schneier.com/news/archives/2012/02/bruce_schneier_on_tr.html

quickfur · 2024-07-26 16:48:11

Secure Boot has always rang hollow for me. It's like MS is trying hard to shout louder to drown out the voices customers calling Windows insecure. "We have Secure Boot! It's Secure! Cuz we named it so! Trust us! It's Secure, people, Secure! That's what it's called!"

What use is Secure Boot when the rest of the OS is designed in an inherently flawed, insecure way? The chain is only as strong as its weakest link.

Not to mention that all the usual implementations of Secure Boot manage to achieve is to make things needlessly harder for users of alternative OSes like Devuan to install the OS of their choice.

Micronaut · 2024-07-26 16:56:10

Not to mention that all the usual implementations of Secure Boot manage to achieve is to make things needlessly harder for users of alternative OSes like Devuan to install the OS of their choice.

You say that as if it's an accidental side-effect.

Andre4freedom · 2024-07-26 17:34:15

First there was a BIOS to boot a system - history
Then came EFI, a firmware that allows to do with other architectures and other, bigger disk layouts. That was welcome.
Then came MS: "embrace and extend!" to exclude all other solutions and manufacturers.

The "UE" in UEFI (former EFI) means User-Extensible or something like that. It implements "Secure Boot", which helps Microsoft to lock out all competitors or OSes. Now Microsoft will "sign" kernels and other software.
They tried first to make the "Secure Boot" option mandatory in the EFI-setup, but thank god the mainboard manufacturer objected to that, and got support from some authorities.

The SystemD-crowd (L.P. and others) suggest to render the MS-type boot-process the default in the Linux-world. How is that??

quickfur · 2024-07-26 20:11:55

@Micronaut: accidental or not, MS embraced it because it helps their cause. Of excluding OSes other than their own.

It's well-known that LP admires MS. Surprise, surprise, after producing the monstrosity known as systemd, he up and went to work for MS directly. Coincidence? I think not.

golinux · 2024-07-26 20:33:09

Unfortunately. . . wailing and pulling of hair over and over does little to turn the tide. It only wastes Devuan resources and perhaps provides therapy for those with nothing more constructive to do . . .

nahkhiirmees · 2024-07-27 17:06:54

It would be useful to be able to check if 1st MB of primary HDD/SDD or an entire /boot -partition have been suffering a bitrot or a malware infection.

Maybe with Coreboot i can do that?

Some BIOSes have a similar feature but i haven't yet confirmed if that works or not. Those old machines succumb to Alzheimer too quickly.
And i've been having some UEFI-related problems too, so haven't had the time or energy to find out what UEFI's can and cannot do, regarding to that "HDD/SDD-protection".

I guess with elder hardware, i'm more likely to run into bitrot. Not in the customs of clicking a wrong link in email while logged in as root.

quickfur · 2024-07-27 20:06:14

Running a browser as root is already a very bad idea... what follows is only details.

nahkhiirmees · 2024-07-28 19:44:01

I rarely even log into X as root. I think about 1-2 years ago i had to, after screwing up with slim somehow.

But anyways. I have browsed grub's documentation, it seems that it can verfify signatures. So it should be possible tp sign the whole kernel and initrd. So no need to use openssl to sign every module that goes into initrd.

And if /boot-partition doesn't change too often, it may be practical to calculate hash of the whole partition and store it somewhere. To check just before giving control from firmware to bootloader. And warning user if content has changed.

Unattended access could be bigger problem with laptops than with desktops, i thjink.

Maybe {Core/LIbre}boot could be run inaide a vm? Would like to find out how that software works in practice.

Last edited by nahkhiirmees (2024-07-28 19:45:10)

quickfur · 2024-07-28 21:01:05

I wouldn't even log into X as root, ever. Just way too much code running as root that does not need root access. It's a very big risk. All it takes is one flaw in the millions of lines of code in the X code base, or any of the associated utilities and programs, and you're screwed.

lynch9 · 2024-07-28 21:44:33

Secure boot just kind off sucks, it can be quite a hassle to manage and update keys, especially if you’re dealing with custom or older hardware like me..

@nahkhiirmees
Running {Core/Libre}boot in a VM sounds like a cool idea, actually. It’s like trying out new firmware without committing to the hardware. Just don’t expect it to be the exact same experience as the real deal i guess aha

@quickfur
Totally agree. Logging into X as root is too risky with all that code running. A single flaw could be a major issue there... best to keep root access limited and avoid unnecessary risks :p

Last edited by lynch9 (2024-07-28 21:47:28)

The officially official Devuan Forum!

#1 2024-07-26 07:53:55

Secure Boot probably not as secure as users would prefer

#2 2024-07-26 16:48:11

Re: Secure Boot probably not as secure as users would prefer

#3 2024-07-26 16:56:10

Re: Secure Boot probably not as secure as users would prefer

#4 2024-07-26 17:34:15

Re: Secure Boot probably not as secure as users would prefer

#5 2024-07-26 20:11:55

Re: Secure Boot probably not as secure as users would prefer

#6 2024-07-26 20:33:09

Re: Secure Boot probably not as secure as users would prefer

#7 2024-07-27 17:06:54

Re: Secure Boot probably not as secure as users would prefer

#8 2024-07-27 20:06:14

Re: Secure Boot probably not as secure as users would prefer

#9 2024-07-28 19:44:01

Re: Secure Boot probably not as secure as users would prefer

#10 2024-07-28 21:01:05

Re: Secure Boot probably not as secure as users would prefer

#11 2024-07-28 21:44:33

Re: Secure Boot probably not as secure as users would prefer

Board footer