Install Secure Boot in Linux

Secure Boot is a critical security feature that is integrated within the Unified Extensible Firmware Interface (UEFI), which serves as a modern replacement for the traditional BIOS firmware interface.

The primary function of Secure Boot is to authenticate the boot process of a computer system by validating the digital signatures of all components that are loaded during system startup. This includes not only the operating system kernel but also various drivers and other essential software components.

The process begins when the computer is powered on. The UEFI firmware initiates the boot sequence and checks the digital signatures of the bootloader and other critical components against a database of trusted signatures stored in the firmware. If the signatures are valid and match those in the trusted database, the boot process continues, allowing the operating system to load. Conversely, if any component is found to have an invalid signature or is not recognized as trusted, Secure Boot will prevent it from executing, effectively blocking potentially harmful software from running.

This mechanism is particularly important in the context of modern computing, where the threat landscape is constantly evolving. By ensuring that only software with legitimate signatures is permitted to run during the boot sequence, Secure Boot significantly reduces the likelihood of malicious software, such as rootkits or bootkits, gaining control of the system at a very early stage. These types of malware can be particularly insidious, as they operate below the level of the operating system and can evade detection by traditional security measures.

Rufus Fixes Creation of Persistent Ubuntu 24.04 USBs

Building Your Own Nixie Tube Clock with HTML, CSS, and JavaScript

Moreover, Secure Boot contributes to the overall integrity of the system by ensuring that the software environment remains consistent and trustworthy from the moment the system is powered on. This is especially crucial in enterprise environments, where the security of sensitive data and systems is paramount. Organizations can configure Secure Boot to enforce specific policies regarding which software is allowed to run, thereby enhancing their security posture.

In addition to its role in preventing unauthorized software from executing, Secure Boot also plays a part in the broader context of system integrity and trust. It is often used in conjunction with other security technologies, such as Trusted Platform Module (TPM), which can provide additional layers of security by storing cryptographic keys and ensuring that the system has not been tampered with.

Overall, Secure Boot is an essential feature that helps to safeguard the boot process, ensuring that only trusted software is loaded and executed. By doing so, it plays a vital role in protecting systems from a wide range of security threats, thereby contributing to a more secure computing environment.

Secure Boot is now present not just on Intel-based devices but is also available for ARM and other architectures.

However, I have noticed that because the process of signing custom kernel builds or third-party drivers can be complicated, many people commonly disable Secure Boot, ignoring its security benefits in a modern environment.

Prerequisites

Before getting into the process of enabling Secure Boot in a Linux system, certain prerequisites need to be in place.

Secure Boot operates in conjunction with UEFI firmware. Ensure that your hardware supports UEFI and that Secure Boot can be enabled in the UEFI configuration. Most of the time, these changes need to be made manually through the UEFI configuration interface by a physically present user. In some cases, you may be able to do so through the Intelligent Platform Management Interface (IPMI) or a vendor-specific remote management interface.

At this point, you should keep Secure Boot disabled as an unsigned boot loader if your Linux distribution was not installed with Secure Boot; the kernel will not load if Secure Boot is enabled. Your UEFI may display an error or simply refuse to boot the kernel.

The exact error message you get is vendor dependent. The above screenshot is from QEMU (a virtual machine emulator). Dell UEFI will display a red box with the message “Invalid Signature detected. Check Secure Boot Policy in Setup.”

If your system has been installed using the Compatibility Support Module (BIOS emulation within UEFI), you may have to switch to a UEFI-based boot. This procedure is outside the scope of this article. If you are interested in such an article, please put a note in the comment section. However, most systems in the last 5–7 years will likely have been installed using a UEFI-compatible method.

In most cases, your UEFI has a key from Microsoft preloaded by the hardware vendor, although some keys may have since been deprecated (see CVE-2023-24932). Make sure you have the latest version of your UEFI firmware for your hardware, and if necessary, follow any instructions you can find from the hardware vendor to update the UEFI firmware, Secure Boot keys, and Trusted Platform Module (TPM) chips to mitigate any key revocation issues.

To verify whether your system is already running with Secure Boot, run the following command:

Enabling Secure Boot in Linux

Secure Boot operates based on keys signed by a trusted authority. As we have discussed, your UEFI likely has the Microsoft key preinstalled. Both Red Hat Enterprise Linux 9 and Ubuntu allow you to enable Secure Boot during the setup of the operating system. However, if you did not enable Secure Boot during installation or upgrade from an older version, you may have to enable it manually.

To load a Linux kernel, a shim signed by Microsoft and your Linux distro (e.g., Canonical for Ubuntu or Red Hat for Red Hat Enterprise Linux) must be loaded. In addition, you must install a signed boot loader (GRUB EFI is the standard loader for most current distros).

It is likely that the default kernels already are signed. Even if you have disabled Secure Boot, you can explicitly install the signed shim and GRUB EFI on Ubuntu.

Now reinstall the GRUB boot loader on your boot device with the UEFI Secure Boot option. To find your boot device, run this command, which looks up and returns the device your boot partition is on (in my case, this is /dev/nvme0n1p2)

After configuring the bootloader, reboot the system and access the UEFI settings to enable Secure Boot. Ensure that the system boots successfully with Secure Boot enabled and that all necessary components are verified during the boot process.

You can verify that Secure Boot is now enabled once again by running this command:

mokutil —sb-state

Enrolling or restoring a Machine Owner Key (MOK)

If you are installing the recommended packages and third-party drivers from your Linux distro’s repository, it is very likely that they have already been signed with the distro’s signature and will load without a problem.

However, sometimes you want to install custom drivers or software that is not or cannot be signed by your distro. This includes antivirus packages, a beta version of the Linux kernel, or a more recent GPU driver than is available in the available software repositories.

Occasionally, people accidentally wipe the MOK database from the UEFI settings. In this case, you will need to enroll or reenroll the public key from the vendor. If you are restoring a system, the certificate with which your kernel was signed will be here: /usr/share/doc/kernel-keys/<kernel-version>/kernel-signing-ca.cer

Import the public key from the vendor using mokutil:

Verify the signature of the key you have just loaded against the signature the vendor presents in its documentation.

You will have to enter a single-use password twice. Now reboot the machine. There is typically a brief timeout to enter MOK Manager before the system continues to boot as normal. If you did not get to the machine in time, simply reenroll and try again. The MOK Manager allows you to inspect and enroll the key in firmware, verifying the password you provided during the enrollment process. Again, you should verify that the key is the correct one you have from the vendor. A user must be physically present at the device to enter MOK Manager and type in the password.

You can, at this point, review the public key information to make sure it is the same as the one you loaded.

After you have enrolled the key, the signed driver should now load. You should destroy the private key if you generated one or put it in a secure location for future signing.

If you ever need to remove a key from the Machine Owner Key database in the UEFI, you can do so by exporting a list of public keys. This generates a list of all public files. You can then review and specify the file containing the public key to delete.