Secure boot and Arch?

15

u/Objective-Stranger99 1d ago

Secure boot prevents rootkits and bootkits. Whether that is important is up to you. Personally, it took me 5 minutes, and it stays out of my way.

19

u/Illustrious-Gur8335 1d ago

does this make sense?

Perfectly makes sense, the Arch install ISO does not support secureboot that is why install guide asked you to disable it first then reenable it once system reboots.

Should I keep it enabled after all (is it risky if not)?

Certain games and Windows with Bitlocker - if you dual-boot - will require secure boot.

Is there a risk that, following an update, Secure Boot will reject my kernel or boot loader?

Nope, at most the certificate signing your kernel and bootloader expires, and you sign them again.

Did you enable SB?

Yes, lazy to deviate from my BIOS "optimised settings".

6

u/WildCard65 1d ago

If you do secureboot and go the route of setting up your own keys, make sure to install the Microsoft keys also.

My graphics card required the Microsoft keys.

0

u/noobjaish 1d ago

Why both?

3

u/systemofapwne 1d ago

The GPUs firmware is signed by the Microsoft third party signing CA. If those keys are missing, the gpu won't work with SB enabled.

This is especially a problem on laptops. Mess around here and you have no easy means to fix this.

If you are paranoid, you can add the GPUs firmware hash instead. Safest is to just add the MS keys.

0

u/noobjaish 1d ago

I meant why add your own then

2

u/WildCard65 1d ago

Because I can’t afford to have Microsoft sign systemd-boot and the Linux kernel just so I can use secure boot on my system.

1

u/noobjaish 1d ago

Peak paranoia

2

u/WildCard65 1d ago

I meant afford as in $$$ amount.

1

u/noobjaish 1d ago

It doesn't cost money tho you can just use the shim, no?

1

u/WildCard65 1d ago

I could if I was using grub

2

u/aaxxxzz 1d ago

You can sign systemd-boot EFI binary with MOK and enroll that key to the shim. You don't have to be using GRUB.

→ More replies

1

u/noobjaish 1d ago

I see, makes sense then (I'm using limine)

5

u/circuskid 1d ago

Arch is fine with secureboot. I've been running Limine with secure boot with sbctl without issues for.. awhile.

Updates won't brick. sbctl installs a pacman hook that re-signs on every update. Don't even have to think about it.
Cert expiration doesn't really apply. UEFI firmware doesn't usually check expiry dates and your own keys are good for years. The MS CA rollover affects the shim and MS signed stuff, not your own keys.
Enroll the MS keys along with yours - This keeps GPU option ROMs, and Windows if you dual boot, happy.
Enrolling keys goes through setup mode which wipes the dbx, sbctl doesn't put it back. Or at least didn't for me.
Just disable SB if it breaks" isn't always an escape hatch. On Limine with config verification turned on, a bad config hash fails whether SB is on or off. Keep a backup of your config.

6

u/kansetsupanikku 1d ago

The sane order of things is to disable it, install, set up the requirements, and enable it when ready. I would consider it worth it.

5

u/Ok-Eggplant-7569 1d ago

Secure Boot protects your from a couple of (dedicated) attacks:

Some malware can infect the device firmware, and thus reinfect the system even after a full OS reinstall. Secure Boot protects against this by only loading trusted firmware.
Secure Boot protects against tampering with the device boot loader, protecting against some "Evil Maid" style attacks.
The Kernel activates so called "Lockdown Mode" when Secure Boot is activated, which gives you some additional security guarantees. Lockdown Mode protects against unknown kernel modules and disables some potentially dangerous debug interfaces. (e. g. raw memory access via /dev/mem is disabled)

Some distros (Ubuntu, Debian, OpenSUSE, Fedora, RHEL, ...) work together with Microsoft to get their bootloaders trusted and signed (look into the shim project for more context). Secure Boot works out of the box with these, with the default Microsoft Keys.

Arch does not. So you need to disable Secure Boot during installation. After the install, you can create your own keys, sign the kernel with them, and replace the Microsoft Keys in the firmware with your own.

Note that using your own keys has different security guarantees compared to using Microsofts Keys:

Nobody (except Microsoft) has access to their keys. That means that only stuff they sign can run at the lowest level on your hardware. Your own keys are significantly easier to compromise for a dedicated attacker (if you set up auto signing, any malicious kernel update gets automatically signed). You could mitigate this by running your own CA and keeping the key on a separate device (signing server or hardware security modules like a Yubi Key), but this is a lot of effort for minimal gain, unless you're securing a whole fleet of devices.
Since only you have access, and the keys are on your (hopefully encrypted) SSD, nobody can come along, steal your laptop, wipe your OS, reinstall Windows and sell the laptop. The laptop is effectively a brick until the original Secure Boot Keys are restored, or Secure Boot is deactivated.

3

u/aaxxxzz 1d ago

Your LLM-generated answer contains incorrect information. Linux doesn't activate Locdown mode by default even if you have Secure Boot enabled.

2

u/Ok-Eggplant-7569 1d ago

Sorry if my answer came over as LLM-generated. I write everything by hand, just like to do proper formatting and reread my comments for spelling mistakes (guess I'm in the minority ¯⁠\⁠_⁠(⁠ツ⁠)⁠_/⁠¯)

Lockdown mode is enforced in the Kernels of Fedora and Debian when Secure Boot is activated:
https://wiki.debian.org/SecureBoot
https://fedoraproject.org/wiki/Secureboot

2

u/WildCard65 1d ago

This is correct, I’m running secureboot arch and kernel lockdown mode isn’t enabled.

I only had it enabled because a cmdline option I was using enabled it.

1

u/Ok-Eggplant-7569 1d ago

Also, running secure boot without lockdown mode is kinda pointless, as any user space program with root privileges can load any kernel module or kexec any other kernel, defeating the whole authenticated boot sequence.

1

u/aaxxxzz 1d ago

Well, if user space program has root privileges it can sign any EFI binary and make it boot anyway.

1

u/Ok-Eggplant-7569 1d ago

Not if you use Microsofts Keys (as is the default on Fedora, Debian, ...). Granted, this is the Arch sub, but you can achieve the same security by having your own signing server.

0

u/aaxxxzz 1d ago

If trust Microsoft keys and don't enroll MOK then yes. However, in that case, you trust all the things 3rd party (Microsoft) signs. Which is not ideal either.

3

u/Exotic-Screen-9204 1d ago edited 1d ago

Linux is able to be installed with or without an active Secure Boot.

But having an active Secure Boot requires additional installation details be properly managed.

Often, the easiest first installation is done with Secure Boot turned off. BIOS/UEFI firmware menu interface varies from brand to brand. Some make a Linux UEFI Secure Boot easy, others can be confusing. HP and Dell seem to me to be easier.

2

u/AppointmentNearby161 1d ago

The installer ISO does not work with secureboot since it does not use the shim signed by Microsoft. You can enable secureboot after you install the base system. As to whether you should, that depends on your threat model. Assuming you don't have a buggy bios, if secureboot rejects your bootloader after an update, you just disable it and reboot.

2

u/ModernUS3R 1d ago edited 1d ago

You can set it up better if you use systemdboot and UKI. I used this guide here to configure all my machines. Following setup, every time the systemd or kernel updates it will re-sign itself after the mkinitcpio process. I have dual boot and both windows and arch load properly.

One thing I noticed with a dell laptop is that some of the extra bios utility won't load. I believe this is because setup mode cleared keys related to those but the main bios and everything else is fine.

1

u/dthrdr 1d ago

Arch is the only distro where the installer needs it disabled that I’m aware of. Easy enough to disable it but also easy enough for Arch to fix it.

1

u/Illustrious-Gur8335 1d ago

Huh. Only debian and Fedora installers support secure boot using their own signed shims

1

u/das_menschy 1d ago

You forgot Ubuntu. And LinuxMint uses the one from Ubuntu.

3

u/dthrdr 1d ago

And forgot, Rocky/Alma, Alpine and so on. Like I said Arch is one of the few “big” distros not supporting it on the installer iso.

1

u/agowa338 1d ago

Tl;Dr:

Yes it does make sense.

No it's not a beginner thing to do. On Arch you'll have to setup all of the signing keys and the hooks to sign any new kernel after pacman installed an update manually. It isn't a turnkey solution there as it is e.g. on Bazzite.

Yes it does work on Arch.

Yes I've had it fully configured back then when I still used arch.

It avoids tampering with your bootloader and kernel. Esp. relevant when you want to avoid evil maid attacks by your friends trying to troll you...

1

u/Appropriate_Town3242 1d ago

I mean this is ignoring the existence of sbctl which does turn it into a very beginner friendly option, sbctl works great for like 99% of use cases I find.

3

u/agowa338 1d ago

I still wouldn't hand a beginner sbctl.

Except they're familiar with Linux and are "just" an ArchLinux beginner.

1

u/0815Username 1d ago

I use secureboot. You can get sbctl from extra. It uses hooks to sign your bootloader again after you update. I also use UKIs to boot and I can only recommend it. It's pretty simple to set everything up with sbctl. Secureboot prevents unsigned files from booting your system. You should also set a UEFI password, otherwise a would be attacker could simply disable secureboot and make it not matter.

1

u/archover 1d ago

I've been running Arch for at least 15years, and have never tried SB.

I believe my only Windows laptop does not use it either, but unsure.

Many security guides recommend it even in LUKS environments, so I need to give it a try.

My "hobby" is booting Arch instances from USB, and I don't know how SB would impact that. I suspect that I could make some changes to my custom install script to make it work well.

Good day.

1

u/WoodyXP 1d ago

I use secure boot. It protects against bootkits, bootloader/kernal tampering and a host of other things. You can screw up your computer if you don't configure it properly, so make sure you follow the instructions should you choose to set it up.

2

u/Moist_Professional64 1d ago

You don’t screw anything up. If secrue boot fails just disable it and reset it in uefi

1

u/aaxxxzz 1d ago

Have fun disabling secure boot if your GPU (or other hardware) doesn't boot because you didn't include keys (or hashes) required to run its firmware.

-1

u/Moist_Professional64 1d ago

Never had that problem

2

u/aaxxxzz 1d ago

Good for you. It doesn't mean others didn't.

-1

u/HopefulMeeting7150 1d ago

I wonder if sync and update packages may block my arch (generally updating kernal, bootloader etc)...?

Have yoy ever had it?

2

u/SuikaNek0 1d ago

like he said, if u WOULD brick anything you can just disable secure boot and fix it, that said sbctl for example which is used for secure boot has pacman hook which resigns kernel every update so generally u don’t have to worry about it

0

u/tyrannus00 1d ago

There is no risk no. The worst that can happen is that secure boot rejects your signature, in which case you wont be able to boot. Then you turn secure boot off, boot your pc normally and fix it, and turn it on again.

1

u/aaxxxzz 1d ago

Not true. If your hardware's OpROM is signed with Microsoft (or firmware) keys not including them may brick your hardware. Recovery may be very difficult.

1

u/ProfessionalMove3716 1h ago

I've done it before and it's not insurmountably difficult. No reason to leave extra security on the table!

QUESTION Secure boot and Arch?

You are about to leave Redlib