Why there are distros without Secure Boot by default recommended?

Privacy Questions
1

Hi -

I was going through the list of recommended distros and I found curious that it has options that don’t support secure boot:

Isn’t it recommended that we opt for distros that support secure boot?

Thanks

1 Like
2

Secure boot is just a nice-to-have, not a make or break thing

3

As far as I know, the only distros with secure boot support (by default) are Debian/Ubuntu, Fedora/RHEL and openSUSE/SLE. So I guess Arch and NixOS are the debatable ones.

4

We don’t require secure boot by default, because even among distros which support it by default the functionality that it provides is very limited. I’ve explained why this is the case on a different site before:

You can have secure Secure Boot on Linux, but you pretty much always have to do it yourself at the moment. Arch wiki has information on doing so, but this won’t be available by default on Linux for a long time for a variety of reasons.

3 Likes
5

Hi - This is interesting. The message to me is that secure boot that is in distros like Ubuntu, Fedora, Debian and OpenSuse isn’t enough and therefore there isn’t advantages over distros that don’t have it. I may be extremist in my words but that is how this is coming across and that is probably what made you guys decided to ditch this criteria basically. Just trying to make sure that I understood this right.

Quick question, when we say that we can have secure boot on Linux and follow the “fix” to create an unified kernel image that combines the kernel, initramfs, and microcode into one single package to be signed for secure boot purposes, do we need to re-sign the custom keys created in every kernel update? Will that have impacts on Nvidia official drivers?

6

If you do use secure boot, be sure to use fwupd to actually install an updated key database.
This will disable know bad/leaked keys.

2 Likes
7

There is an advantage I mentioned, which is that the secure boot implementation should limit persistent malware to running in the user space rather than infecting the kernel space itself. This doesn’t make the malware less harmful necessarily, but it does make it likely easier to detect than malware running in the kernel space would be.

This advantage isn’t enough to justify creating a secure boot criteria for our recommendations though, IMHO.

8

Assuming that you feel confident enough in your specific knowledge on the topic to answer. I have a couple follow up questions:

  1. To what extent is the above applicable to OpenSUSE (or any other distro where /boot is encrypted). It seems to my unsophisticated eye, that encrypting /boot, extends the coverage encryption provides from 6 → 7 to 4 → 7 (because the kernel and initramfs are stored in /boot, if /boot is encrypted it seems they could not be tampered with prior to decryption).
  2. In cases where /boot is not encrypted, could the TPM assist in verifying 4 → 5 → 6
  3. What is the caveat you alluded to with Grub.
9
  1. I’m unfamiliar with how openSUSE works in this regard, is /boot accessible (decrypted) when the laptop is booted? I would imagine it is to facilitate updates. If so then you’re not really protected from malicious modifications… this is one reason I suggested an external /boot partition could serve as an easier (but not quite as good) secure boot alternative. I don’t see much benefit to merely encrypting /boot and not doing anything else though.
  2. Sure, but only if the kernel and initramfs are bundled together in a unified kernel image (as brought up earlier). The reason for this is that the kernel has no built-in tool for verifying initramfs on boot, so the only way for the bootloader to verify your initramfs is if it does it as the same time as it verifies the kernel.
    • When you use a unified kernel image, my simplified boot process would change to:
      1. EFI
      2. shim pkg
      3. bootloader
      4. unified kernel image
      5. init system
      6. user space
    • …and the secure boot process should verify 1-4 (5 and 6 are protected from modification when powered off by full disk encryption, and of course are not protected when the system is powered on because it’s a writable operating system)
  3. I don’t remember what specifically I was referring to now lol - I haven’t used grub in a looong time. I will say that grub is incredibly complex compared to systemd-boot, probably something to do with it.
#2 bonus

something else, if you use custom keys and stuff, EFI can technically load the kernel directly without any shim/bootloader middlemen (with EFISTUB booting). So if you were obsessed with reducing your trust chain as much as possible, it should be doable to have a setup like:

  1. EFI
  2. Kernel EFISTUB w/ built in initramfs
  3. init system
  4. user space

… would I recommend this? :man_shrugging:

1 Like
10

Secure boot to me is an additional security benefit. I have no reason to switch to a non-secure boot system.

Moreover, disabling secure boot on a laptop (the last time I used desktop PC was 20 years ago) would require me to remember the BIOS password. There’s a way to recover the password depending on the laptop brand, though. It’s nothing but a hassle to disable secure boot.

1 Like
11

Would Arch be the first distro to offer this as an option during installation?

12

Well archinstall isn’t Arch’s default installation process, but that is pretty cool!

Edit: oh I guess it will be lol

Archinstall 2.7 will also be the default installer in the upcoming Arch Linux ISO snapshot for December 2023.

13

Archinstall is already bundled with the ISO image. Not sure if that makes it the official installer or whatever, but it has been bundled with it for a few years now.

14

Note: this whole comment is will be written in the context of one particular type of threat secure boot is designed to protect against. Adversaries with physical access to the system (so not malware already present on the system, not an attacker that already has root, etc).

So my understanding is that a typical simple encryption scheme using LUKS in linux is

  1. an unencrypted partition for all of /boot (which contains the bootloader, kernel, initramfs)
  2. a second partition encrypted with LUKS where everything else is mounted (root, home, etc)

OpenSUSE modifies this slightly:

  1. an unencrypted partition solely for /boot/EFI (the bootloader)
  2. a second partition encrypted with LUKS where everything else (including /boot will live).

So, to the best of my understanding, the main difference with respect to security, is that with the SUSE approach, the only thing that is not encrypted at rest is /boot/EFI which only stores the bootloader. Compared with in the traditional approach where the bootloader, the initramfs, and the kernel are all unencrypted at rest.

This is not sensitive data, so many people don’t see this as a risk, but in the context of physical threats/evil maid/tampering with the boot chain, I’d think that having most of /boot encrypted would prevent an adversary with physical access from tampering with or modifying either the kernel or initramfs because they would be encrypted. So basically it would be applying the same form of security as your explanation of “6 → 7” to the 4th and 5th links in the chain (kernel and initramfs). So while it’s not verifying these steps in the chain like secure boot would, it is making it so an attacker with physical access could not observer or modify initramfs or the kernel at rest because they would be encrypted.

If I understand correctly, this approach improves security with respect to an adversary with physical access to the system, but would not protect against malware that makes its way onto the system in some other way. But physical threats are one of the main things secure boot is designed to protect against and based on your explanation of the current shortcomings of secure boot not protecting 4 - 5 -6 in the boot chain, it seems that the OpenSUSE approach would eliminate that gap to some degree. Does that make sense?

Bascially TL;DR is, if I understand correctly, with the OpenSUSE approach the same protection you outlined below (and the same limitations would be extended to also apply to the kernel and initramfs:

5 and 6 are protected from modification when powered off by full disk encryption, and of course are not protected when the system is powered on because it’s a writable operating system

I want to stress, while I have looked into this a few times over the years, its at the edge of my technical competence, so don’t accept it uncritically.

other considerations

(also I won’t get into the details, but there are some important practical pros/cons unrelated to security as to why one would choose to encrypt boot or not, if you’ve noticed decryption is slower on opensuse than other distros, this is the reason why, performing decryption earlier in the boot process means no hardware acceleration and no pretty password prompt. On the flip side, the primary non-security-related advantage for distros like OpenSUSE that use BTRFS or ZFS, is not having a separate /boot makes snapshots and rollbacks simpler and better).

4 Likes
15

Yes in that case when the device is fully powered off, and secure boot is enabled, and you have a UEFI password set to prevent changes to your secure boot configuration, and shim(mokmanager) is configured with a password to prevent people with physical access from installing custom secure boot keys (which I believe openSUSE does do by default), that should protect you against classic evil maid attacks.

I would argue that other threats (e.g. bootkits) are probably more relevant to most people though, and those would not necessarily be impacted like you mentioned. There are also other evil maid attacks you’d still be susceptible to, like a networked attack where your entire device is replaced with an identical one, so of course it’s not like physical threats are even eliminated either.

16

I didn’t know this. Is OpenSUSE the only distro that encrypts this way?

17

It is possible to do yourself manually from the terminal during install with most distros and a documented option in the Arch Wiki, but OpenSUSE is the only one I’m aware of that does so by default or offer it as an option from the GUI installer.

I’ve done so in the past manually with Arch and with Ubuntu, but its a bit complicated and takes some time/research compared to a traditional encryption scheme so its nice to have see OpenSUSE including it as a supported option.

2 Likes
18

It might be worth mentioning this advantage of OpenSUSE’s encryption in a sentence on the PG recommendations page then? @jonah

This is an example for the default encryption when you just tick [x] encrypt disk in the installer:

# lsblk /dev/sda
NAME        MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
sda           8:0    0   20G  0 disk  
├─sda1        8:1    0  512M  0 part  /boot/efi
├─sda2        8:2    0 18.3G  0 part  
│ └─cr_root 254:1    0 18.2G  0 crypt /var
│                                     /usr/local
│                                     /srv
│                                     /root
│                                     /opt
│                                     /home
│                                     /boot/grub2/x86_64-efi
│                                     /boot/grub2/i386-pc
│                                     /.snapshots
│                                     /
└─sda3        8:3    0  1.2G  0 part  
  └─cr_swap 254:0    0  1.2G  0 crypt [SWAP]

There’s some downside to the comfort, as mentioned before, namely that the disk decryption takes a bit longer than on Fedora/Ubuntu (for me about 5-10 seconds for a 2 TB SSD) and that you don’t get a nice password input screen but just a terminal asking for your password before you even get to the Grub boot menu.

2 Likes
19

cryptsetup uses a timed benchmark to calculate iterations and ram usage
if you put a drive created on a fast computer into a slower one it’ll take longer
its goal goal is 1-2 seconds, you can see this with cryptsetup --help and see the default section at bottom

benchmark on a slower computer can actually result in weaker settings, eg. 512MB at 1-2 iterations

I actually recommend people manually set a higher iteration count and RAM usage for their keys, eg:

sudo cryptsetup luksConvertKey /dev/nvme0n1p3 --pbkdf argon2id --pbkdf-memory 4194304 --pbkdf-parallel 4 --pbkdf-force-iterations=16

takes about 5-15 seconds on my modern Ryzen machines and uses 4GB of ram to unlock the slot

you can see what you’re currently using with sudo cryptsetup luksDump /dev/whatever

4 Likes
20

With arch you’re expected to set it up yourself. The reason for this is because there are a variety of different ways of doing so, some more secure than others.

If we’re considering arch in this regard it has some of the best secure boot support with tools like sbctl packaged and pacman hooks to sign a unified kernel image (initramfs+kernel) with a custom key. You of course need to configure dracut to make a unified kernel image with the uefi option if you want to have signed initramfs too.

To my knowledge none of the other distributions offer this and only have the shim method.

nixos has a specific way of doing it too, using nix config which also appears to be powered by sbctl.

4 Likes