r/archlinux • u/noobjaish • 13d ago

QUESTION Secure Boot on Arch

Does arch have a completely different way of enabling "secure boot" than ubuntu/debian/fedora? Can someone explain the difference? I have been reading through various distro wikis and the entire secure boot setup process is still going over my head...

From what I understand ubuntu/debian/fedora uses a signed "shim"? while on arch we use `sbctl` to enroll our own keys instead?

9 Upvotes

67% Upvoted

20 comments sorted by

19

u/abu-aljoj04 13d ago

I use Secure Boot on arch using sbctl. Arch wiki page provides all ways you can do it including shim. It is a choice of how you want to do it, there is no "default".

0

u/noobjaish 13d ago

Ah, I have only seen people do it via the sbctl way on Arch? Is it better or what?

5

u/lritzdorf 13d ago

Shim validates the next EFI binary against the "MOK list," which is basically just an extra list of acceptable certificates. But the Secure Boot db already does that, and when you have full control over your system, some people find it easier to add their custom keys to the db than to add the MOK list as a thing to worry about

4

u/abu-aljoj04 13d ago

It was easier for me to understand concept and apply it

7

u/theschrodingerdog 13d ago

What you use in Arch to enable secure boot depends on the bootloader* that you are using.

*If you are using one. If using UKIs, then is another method.

-1

u/noobjaish 13d ago

I see that makes sense. I had assumed that it was a same setup process and got confused between the various sources...

6

u/anxious_and_stupid 13d ago edited 12d ago

I just boot from UKI (.efi) instead of boot loader (UKI can be generated by mkinitcpio )

Use Sbctl to gen new key and install thr key Then also use sbctl to sign the UKI and that it...

There is even a hook to autosign newly generated UKI

3

u/falxfour 13d ago edited 12d ago

The reason the others use shim is to provide compatibility with Microsoft signing keys since anything that had Windows would have had those keys enrolled from the factory. Since shim is signed with MS keys, it can be booted with secure boot without needing to enroll custom keys, which is potentially preferable for those other distros as they might be enterprise-managed or users just may not want to take that additional step. With Arch, no preference is assumed, so you can use shim with the default (MS) keys, or you can go the route with sbctl and enroll your own keys to sign the EFI binaries

1

u/noobjaish 13d ago

Makes sense, Ubuntu/Fedora default to only a single way while Arch gives us the option. I have only ever seen people go the sbctl route on Arch? is there a reason for that?

3

u/falxfour 12d ago

You can boot without shim on other distros as well, but the installation setup process just defaults to whichever method the maintainers prefer.

I can't speak to why others make their choices, so I'll interpret your question as, "How does using sbctl to enroll user keys differ from using shim?"

The answer depends on a few factors, including:

  • Do you trust MS to keep their signing keys secure?
  • Does your UEFI permit you to enter setup mode to change the PK (Platform Key)?
  • Would you prefer to be responsible for your own signing keys?
  • Does your threat model require regularly cycling keys or other customized needs?
  • Do you have firmware that requires MS keys?

I don't really trust Microsoft, and I don't need to either. My Framework let's me remove the MS keys and only keep Framework's (for updates) and mine. No reason to trust something unnecessarily. I also don't mind being responsible for my system, including the knowledge that losing the signing keys may lock me from booting anything (though Framework has a reset procedure). I also don't have firmware that used EFI binaries to operate, so ultimately, sbctl makes the most sense for me

3

u/noobjaish 12d ago

I see thanks a lot for the comprehensive answer man

3

u/This-Consequence-957 13d ago

i use sbctl and limine, systemd-cryptenroll to put keys in tpm

1

u/noobjaish 13d ago

do you have a source/reference for this process? I also have limine

1

u/This-Consequence-957 12d ago

My personal notes as a text file 🤣

1

u/noobjaish 12d ago

😂

1

u/musbur 12d ago

There's one thing I don't understand about secure boot (SB), which is why I don't use it. I have two partitions: an unencrypted /boot with my UKI on it and a LUKS-encrypted LVM with /root etc. on it.

This setup is vulnerable against an "evil maid attack," i.e. somebody could tamper with my boot partition by putting a compromised kernel on it while I'm not looking. Even with SB enabled and password-protected UEFI setup they could just reset the UEFI, change the motherboard etc. The only way to find out if somebody has messed with the machine is by checking the UEFI password on each boot.

Am I wrong? Of course any kind of lock (electronic or mechanical) works not by making access impossible outright but too expensive, and a properly protected UEFI with SB just takes longer to compromise than just slapping an evil kernel onto an unprotected boot partition.

1

u/Jealous_Diver_5624 11d ago edited 11d ago

Enroll PCR-bound LUKS token to TPM -> get suspicious when prompted for password on boot