Modern Linux Security: Hardening the Boot Process with Unified Kernel Images (UKI)

Table of Contents

The Shift to Unified Kernel Images: Why Boot Security Matters

The traditional Linux boot process resembles a relay race with too many hand-offs. Your firmware (UEFI) passes control to a bootloader like GRUB, which then loads the kernel and the initial RAM disk (initrd) from separate files on your disk.

This modularity is great for flexibility, but it leaves the door wide open for attackers. If a malicious actor gains root access, they can swap your initrd for a compromised version. This rogue initrd could capture your LUKS disk encryption password before you even see a login prompt.

I learned this lesson the hard way after a server I managed saw over 4,000 failed SSH login attempts in a single hour. While I blocked the network attacks, it hit me: hardening the network is only half the battle. If the underlying OS boot process isn’t verified, every security layer above it is built on shifting sand. This realization led me to adopt Unified Kernel Images (UKI).

A UKI is a single, self-contained EFI executable. It combines the Linux kernel, the initrd, the kernel command line, and a small UEFI stub into one file. Instead of managing a half-dozen signatures, you sign one binary. Your UEFI firmware verifies this single signature, ensuring your system’s core remains exactly as you intended.

Setting Up the Environment

You’ll need a handful of specialized tools to build and sign these images. Most modern distributions, including Arch, Fedora, and Debian (Sid/Trixie), provide these in their standard repositories. We will use systemd-ukify, which has become the de facto standard for assembling these images.

On Debian-based systems, install the dependencies with apt:

sudo apt update
sudo apt install systemd-boot binutils sbsigntools python3-pefile

For Arch Linux users:

sudo pacman -S systemd ukify sbsigntools

The sbsigntools package is the most critical component here. It provides the utilities needed to apply the cryptographic signatures that your motherboard’s Secure Boot mechanism requires to trust the binary.

Step 1: Generating Your Own Secure Boot Keys

Relying solely on the factory-installed Microsoft keys means trusting a third party with your hardware’s root of trust. To take full control, you should generate your own Machine Owner Keys (MOK). For this guide, we’ll create a 2048-bit RSA key pair specifically for signing our UKI.

# Create a dedicated directory for your keys
mkdir -p ~/secure-boot-keys
cd ~/secure-boot-keys

# Generate a private key and a certificate valid for 10 years
openssl req -new -x509 -newkey rsa:2048 -nodes -days 3650 -subj "/CN=My Custom UKI Key/" -keyout uki.key -out uki.crt

# Convert the certificate to DER format for UEFI enrollment
openssl x509 -in uki.crt -out uki.cer -outform DER

Guard the uki.key file with your life. Anyone who obtains this file can sign a malicious kernel that your computer will treat as perfectly legitimate.

Step 2: Building the UKI with ukify

The heavy lifting happens here. We are going to squash the kernel (vmlinuz), the initramfs, and your boot parameters into a single .efi file. Using a configuration file for ukify keeps the process repeatable and prevents typos in long command strings.

Create a file named uki-config.conf:

[UKI]
Linux=/boot/vmlinuz-linux
Initrd=/boot/initramfs-linux.img
Cmdline="root=UUID=550e8400-e29b-41d4-a716-446655440000 rw quiet bgrt_disable"
OSRelease=@/etc/os-release
Stub=/usr/lib/systemd/boot/efi/linuxx64.efi.stub

Build the unsigned image by running:

/usr/lib/systemd/ukify build --config=uki-config.conf --output=vmlinuz-unsigned.efi

While ukify can sign images during the build process, I prefer signing manually in the next step to ensure the workflow is crystal clear.

Step 3: Signing the Unified Image

Now we apply the cryptographic stamp. This step attaches your signature to the PE header of the EFI binary, allowing the firmware to validate it against the keys you’ll enroll in the next step.

sbsign --key uki.key --cert uki.crt --output /boot/EFI/Linux/systemd-linux.efi vmlinuz-unsigned.efi

I recommend placing the output in /boot/EFI/Linux/. Modern versions of systemd-boot automatically scan this directory. They will find your .efi files and add them to the boot menu without requiring any manual configuration entries.

Step 4: Enrolling the Keys in UEFI

Your motherboard is currently unaware of your uki.crt. You have two ways to bridge this gap:

MOK Management: If you use a ‘shim’ (the default for Ubuntu or Fedora), use mokutil --import uki.cer. This triggers a blue screen interface on your next reboot where you can confirm the key enrollment.
Custom Keys: You can replace the default factory keys in your UEFI settings with your own. This is a “Pro” move that provides the highest security but requires more effort to maintain.

For most setups, mokutil is the most practical choice:

sudo mokutil --import ~/secure-boot-keys/uki.cer

Set a temporary password, reboot, and follow the “Enroll MOK” prompts in the UEFI environment.

Verification and Automation

Validation is the final piece of the puzzle. Once you’ve rebooted into your new UKI, you need to confirm the security loop is closed.

Checking Secure Boot Status

Run bootctl to inspect your environment:

bootctl status

Look for Secure Boot: enabled. If you see this, your firmware successfully verified the UKI’s signature before allowing a single line of kernel code to execute.

Verifying the Binary Signature

To double-check the file on disk, use sbverify:

sbverify --list /boot/EFI/Linux/systemd-linux.efi

This command displays the certificate details. If the file is tampered with, the verification fails immediately.

Streamlining the Workflow

Manually signing kernels after every update is a recipe for a broken system. On Arch Linux, I use a pacman hook. On other distros, a script in /etc/kernel/install.d/ can automate the ukify and sbsign process. This ensures that every time you run a system update, your security stays intact without manual intervention.

By migrating to UKIs, you eliminate the bootloader configuration as a point of failure. Your kernel and initrd become a single, immutable unit. It is a massive leap forward from traditional architectures and a vital component of any hardened Linux workstation.