Arch Linux doesn't support Secure Boot (for the official install media)

Source

While an user can technically add it’s own keys to Secure Boot, this is complicated and not available on some newer PCs. An alternative is archboot.com

We should add a warning in https://www.privacyguides.org/en/desktop/#arch-linux

Title : Arch Linux doesn’t support Secure Boot
Explanation : Secure Boot help prevents Evil maid attacks. Even if you enable disk encryption, an attacker could bypass this encryption if they had physical access to your computer.

what are you even talking about?

From the docs :

Booting an installation medium
The official installation image does not support Secure Boot (FS#53864). Secure Boot support was initially added in archlinux-2013.07.01-dual.iso and later removed in archlinux-2016.06.01-dual.iso. At that time prebootloader was replaced with efitools, even though the latter uses unsigned EFI binaries. There has been no support for Secure Boot in the official installation medium ever since.

In order to boot an installation medium in a Secure Boot system, you will need to either disable Secure Boot or modify the image in order to add a signed boot loader.

Archboot images provide a way to use secure boot on installation media.

If you’re worried about compromise during installation, you have bigger issues than no secure boot until you set it up.

4 Likes

They do not support secure boot at any point in time. Period. They only point to an hacky way of adding your own keys, which is not ideal for security.

Actually read the wiki before sounding off like this lmao, here is the exact section.

2 Likes

I already read it, and what I said is correct. What don’t you agree with ?

Are you calling MokList a hacky way to enable secure boot? Or are you denying that Shim or PreLoader exist? Or that they provide secure boot? Like what actually are you arguing when you say “they only point to an hacky way of adding your own keys”?

The whole point of secure boot is to prevent putting a fake OS that resembles the original (and is the same except a few modified systems that are now malicious). Here, this seems severely weakened. Let’s be honest : what percentage of users actually verify their packages ? Less than 10%.**

**Here, a very easy attack would be a fake review site telling people how to install Arch Linux, and even telling them how to set up “Secure Boot”. Except, this website will provide a malicious Arch Linux. With well-implemented secure Boot; such as Fedora’s, Ubuntu’s, Linux Mint’s, etc; this wouldn’t be possible.

I can’t decide on a single argument against what you’re trying to argue here so have all of them:

  1. That isn’t the point of secure boot, the point is preventing tampering with the installed OS. Anti-phishing at the point of installation is not in the remit of anti-evil maid protections
  2. Secure boot on the installer doesn’t even prevent your “very easy attack” if the secure boot implementation is shim or preloader since they’d launch MokManager or whatever it’s called anyway if you say, need DKMS for some hardware’s driver
  3. a) That phishing attack wouldn’t work on someone who’s already on PrivacyGuides and whom the little warning would apply to, since PG links directly to the official Arch homepage anyway, thus making that warning very redundant
    b) Non-technical users are advised to not use Arch basically everywhere, including on PrivacyGuides, giving another layer to the redundancy of the warning
  4. dngray reminded me, yes, there’s the checksums and signatures on the arch homepage too which would prevent this “very easy attack”
4 Likes

You can use secureboot with archlinux, so I’m not sure what this nonsense is all about. Just use sbctl, you can use your own keys too.

It’s a DIY distribution so you’re expected to set it up yourself. As for the installation medium, it’s not necessary because that is going to be read/only and verified via developer gpg signature anyway.

If you use dracut and dracut-ukify you can create your own signed UKIs.

5 Likes

sbctl

this is my sbctl status.

and I, 100%, use Arch btw.

It’s not complicated, considering the background of Arch users. It was only two or three commands in my case. Using a UKI with your own keys is the better approach anyway compared to allowing everything with the Microsoft third-party certificate.

On which ones doesn’t it work?

2 Likes

Enabling secure boot on Arch requires you to :

  1. Enable Setup Mode in your firmware (which is simple and is in secure boot settings in the firmware, it wipes all keys)

  2. Boot into Arch

  3. Type the following commands :

sudo pacman -S sbctl (if you don’t have sbctl)
sudo sbctl create-keys
sudo sbctl enroll-keys -m
sudo sbctl sign -s /boot/vmlinuz-linux (or whatever path to your kernel image in /boot)
sudo sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI (the EFI file of the bootloader - for me, it was /boot/EFI/Arch Linux/grubx64.efi)

It is not the easiest thing in the world. But, it is much better than not using sbctl. sbctl is also made by Foxboron, a Arch Linux developer.

I only quickly scrolled down the thread and didn’t read that reply. Lets return things back to the topic and keep everything civil.

1 Like

Okay everyone, thanks for the answers. I was wrong, as the ways to install your own keys seem secure, because the request has to come from the base OS. I found this Powerpoint which explained it more clearly than the docs which are sometime a bit heavy to read. I still would like default support, but it’s definitely possible to enable Secure Boot.

1 Like

Yes, and if you’re using systemd boot, you’ll be adding /boot/efi/EFI/systemd/systemd-bootx64.efi. There really isn’t much reason to use grub imo. I would also enable unified kernel images.

This file doesn’t acknowledge the existence of sbctl (which, to be fair, is not unexpected considering it came from Arch and not a bigger distro like Ubuntu, Fedora or openSUSE or whatever). And it seems to be 5 years old - even the Linux desktop was in quite a premature state 5 years ago.

Here’s a tip : Always go to the source, and try to find newer content.

Default support in the installer, because Arch supports secure boot after installation seamlessly.

Though again, the installer supporting secure boot isn’t the biggest problem ever and I’m truly baffled as to why you’re still dying on that hill.

2 Likes