Systemd takes steps toward a more secure boot process

The systemd project has been working for some time on promoting unified kernel images (UKIs), a format that bundles a kernel, initial disk image, kernel command line, and other associated data into a single file. The advantage of the format is the ability to authenticate the entire collection with secure boot, which makes it easier for end users to know that their operating system hasn't been tampered with. The downside is the lack of flexibility and increase in disk usage, since all of the things packaged in a UKI must be updated together. But the recent systemd 257 release (along with other changes to be covered in a future article) includes some major changes to the UKI format, and the rest of the boot process, that partially mitigate those downsides. The release also includes improvements for hardware-locked disk encryption, which may also help secure some computers.

Unified kernel images

Perhaps the most onerous limitation of the UKI format was that, since it includes the kernel command line, there was no good way to modify the command-line parameters during boot. This made debugging boot problems painful, but it also meant that distributions that wanted to provide multiple boot options for each kernel (such as one for a recovery shell) needed to provide multiple UKIs, needlessly duplicating the kernel. Despite the downsides, including the command line in a UKI does have security benefits — there are command-line options that disable many of the kernel's security-hardening options, or that may leave the kernel open to attack in other ways.

The recent systemd release solves this problem by using "profiles" that allow for multiple versions of a component to be packaged in the same UKI and selected at boot time. This helps reduce the number of different UKIs needed by a system, while still allowing for secure boot to validate the entire image, including command-line options. Systemd had already allowed for UEFI "add-ons" — additional files verified by secure boot and stored on the EFI partition — that could be used to add to the kernel command line, but having proper support in the UKI format itself is a welcome change. Add-ons are not going to become completely obsolete, however. Their primary use going forward is likely to be providing microcode updates, which usually have a different lifecycle than the kernel.

Another important component of UKIs are devicetrees. These are used on a few architectures to tell the kernel what hardware is present, and how to configure different drivers to support it. Devicetrees have been an optional component of UKIs for some time, but the new version now allows for multiple devicetree files to be packaged in a single image. These can be selected by profiles, but can also be automatically selected based on the IDs of available hardware.

Some devices' firmware actually provides its own devicetree information. The changes to the UKI format also allow shipping devicetrees that can be matched with the devicetrees provided by the hardware, so that one UKI is potentially usable across devices with different hardware. The devicetree in the UKI doesn't have to be identical to the one provided by the firmware, so developers could potentially use this mechanism to provide a patched devicetree if the one provided by the firmware is unsuitable.

To support these changes to the format, there have also been some changes to systemd's tooling. For example, ukify now supports adding new sections onto existing UKIs, in order to help build multi-profile UKIs. bootctl can also now report more information about how exactly the system booted, including reporting any add-ons used.

bootctl also makes it easier to use one's own secure-boot signing keys by setting up a secure-boot database to be automatically installed on first boot of an image. There are a handful of related changes to systemd's security tooling, such as the ability to use OpenSSL providers (including ones that require user interaction to unlock private keys) in more places.

Combined TPM policies

The bigger security news in this update is probably improvements to the ways that systemd can use a system's trusted platform module (TPM) for disk encryption. systemd-cryptenroll is the tool for adding hardware security tokens and devices to a LUKS2 encrypted volume. For a while now, it has supported using TPMs to lock the keys for an encrypted disk. Specifically, TPMs can use platform configuration registers (PCRs) to store secrets that are only released when the computer is running a particular, trusted piece of software. The Linux PCR registry lists what each PCR is used for. The first eight are used by the computer's firmware, with later entries used by bootloaders and the kernel. Generally keys are locked to every step in the boot process — for example, requiring the firmware to attest that it used secure boot, requiring the boot loader to report the hash of the image it loaded, etc.

Depending on how the user configured things, the TPM PCRs could be used either to lock a disk-encryption key to only be used on kernels signed by a particular OS vendor, or to lock a disk-encryption key to specific local things, such as the firmware version, available hardware, etc. Now, with systemd 257, the user can configure both these kinds of requirements at once. In his description of the feature on Mastodon, Lennart Poettering said:

It is my intention to make this good enough so that distributions eventually can default to enable this, and finally provide boot security that is closer to what outside of traditional Linux is the state of the art.

The feature is not without flaws, however. TPMs don't have a native way to combine the two different kinds of policy. So the system uses two separate keys that are each protected by different policies in the TPM, and then concatenates them to form the disk-encryption key. Theoretically, an attacker with hardware access could boot once with the correct OS (but incorrect hardware or firmware, such as adding a debugging device to dump the key once the TPM reveals it), and once with the correct hardware but a corrupted OS, and then combine the two keys to unlock the device. Still, when properly configured, this feature could make it more difficult for attackers to compromise disk encryption.

Of course, encrypting a computer's disk with a key held in the TPM is not always a reasonable choice, depending on one's threat model. Poettering imagines TPM-linked disk encryption primarily being used to secure the disk on which the operating system is installed, especially on unattended servers that may not have a good way to ask for passphrases. User data would be encrypted with a separate key instead of, or in addition to, the key held in the TPM. There are existing solutions to allow disk-encryption secrets to be provided over the network during early boot, but they may not be suitable for everyone. There are many different kinds of computers that run systemd, with quite different security needs. Having additional flexibility could allow users to tailor a setup to their needs.

In that spirit, the update also includes improvements to the use of FIDO hardware tokens. Systemd's crypttab file now has options for the use of hardware tokens, and systemd-cryptenroll has options for listing which available hardware tokens can be used with a given block device, to make the setup easier.

Overall, the systemd project has been pushing toward a vision of being able to comprehensively secure the boot process of Linux systems. This effort has not been entirely without problems — especially because there is often a tradeoff between security, simplicity, and usability — but now that the worst problems of the UKI format have been ameliorated, we may soon see more distributions making use of it.