this post was submitted on 25 Jul 2024
315 points (99.1% liked)

Technology

59534 readers
3209 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. Check for duplicates before posting, duplicates may be removed

Approved Bots


founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] ilinamorato@lemmy.world 13 points 3 months ago* (last edited 3 months ago) (2 children)

Ok, so I am not an expert, and I am not the OP. But my understanding is that Secure Boot is checking with a relatively small list of trustworthy signing certificates to make sure that the OS and hardware are what they claim to be on boot. One of those certificates belongs to a Microsoft application called Shim, which can be updated regularly as new stuff comes out. And technically you can whitelist other certificates, too, but I have no idea how you might do that.

The problem is, there's no real way to get around the reality that you're trusting Microsoft to not be compromised, to not go evil, to not misuse their ubiquity and position of trust as a way to depress competition, etc. It's a single point of failure that's presents a massive and very attractive target to attackers, since it could be used to intentionally do what CrowdStrike did accidentally last week.

And it's not necessarily proven that it can do what it claims to do, either. In fact, it might be a quixotic and ultimately impossible task to try and prevent boot attacks from UEFI.

But OP might have other reasons in mind, I dunno.

[–] cmnybo@discuss.tchncs.de 22 points 3 months ago (3 children)

To use secure boot correctly, you need disable or delete the keys that come preinstalled and add your own keys. Then you have to sign the kernel and any drivers yourself. It is possible to automate the signing the kernel and kernel modules though. Just make sure the private key is kept secure. If someone else gets a hold of it, they can create code that your computer will trust.

[–] NekkoDroid@programming.dev 3 points 3 months ago* (last edited 3 months ago)

The kernel modules usually are signed with a different key. That key is created at build time and its private key is discarded after the build (and after the modules have been signed) and the kernel uses the public key to validate the modules IIRC. That is how Archlinux enables can somewhat support Secure Boot without the user needing to sign every kernel module or firmware file (it is also the reason why all the kernel packages aren't reproducible).

[–] ilinamorato@lemmy.world 2 points 3 months ago

In any case, not for the average person.

[–] jabjoe@feddit.uk 1 points 3 months ago

Your want to store a copy of the private key on the encrypted machine so it can automatically sign kernel updates.

[–] NekkoDroid@programming.dev 5 points 3 months ago (1 children)

And technically you can whitelist other certificates, too, but I have no idea how you might do that.

When you enter the UEFI somewhere there will be a Secure Boot section, there there is usually a way to either disable Secure Boot or to change it into "Setup Mode". This "Setup Mode" allows enrolling new keys, I don't know of any programs on Windows that can do it, but sbctl can do it and the systemd-boot bootloader both can enroll your own custom keys.

[–] ilinamorato@lemmy.world 1 points 3 months ago

Definitely not for the "normie" then.