Fedora has just released test-ready sealed bootable container images for its Atomic Desktop lineup. These images promise a fully verified boot chain from firmware to OS, leveraging Secure Boot and UEFI. If you’re interested in how they work, what they enable, and how to try them safely, here are ten things you need to know.
1. What Are Sealed Bootable Container Images?
Sealed bootable container images are complete, self-contained bootable artifacts that include every component necessary for a cryptographically verified startup process. Unlike traditional disk images, these are built as OCI containers and can be managed with tools like bootc. The “sealed” aspect means the entire boot chain—from firmware to the root filesystem—is signed and integrity-protected, ensuring that only trusted code executes. This is a significant step toward making immutable, container-based desktop operating systems more secure by default.
2. The Core Components of a Sealed Image
Each sealed image bundles three critical elements: systemd-boot as the bootloader, a Unified Kernel Image (UKI) containing the Linux kernel, initrd, and kernel command line, and a composefs repository with filesystem-level integrity via fs-verity. Together, these create a chain of trust that starts with UEFI Secure Boot and ends with the mounted root filesystem. The composefs layer is managed by bootc and ensures that any modification to files is detected immediately. Both systemd-boot and the UKI are signed for Secure Boot, though the test images use non‑official signing keys.
3. How Secure Boot and UEFI Enable Verified Boot Chain
The sealed boot chain relies on UEFI Secure Boot on x86_64 and aarch64. At power‑on, the firmware verifies the signature of systemd‑boot. systemd‑boot then verifies the UKI’s signature. The UKI, in turn, verifies the composefs image using fs‑verity hashes. This layered verification ensures that no stage of the boot process has been tampered with. Because the entire chain is signed, even if an attacker gains physical access, they cannot replace any boot component without breaking the signature validation.
4. The Role of systemd‑boot and UKI
systemd‑boot is a lightweight UEFI boot manager that loads the UKI directly from the EFI System Partition. The UKI bundles the kernel, an initrd, and the kernel command line into a single signed EFI executable. This eliminates the need for a separate bootloader configuration like GRUB. For sealed images, the UKI is patched to include a minimal initrd that mounts composefs and verifies its integrity. The result is a simpler, more auditable boot flow that reduces the attack surface. The UKI and systemd‑boot are signed with test keys (not official Fedora keys) for this experimental release.
5. composefs and fs‑verity for Image Trust
composefs is a read‑only, content‑addressable filesystem that stores file data in a repository and metadata in a separate descriptor. Each file’s content is hashed, and those hashes are protected by Linux’s fs‑verity—a kernel feature that verifies file integrity on every read. In sealed images, the composefs descriptor is embedded in the UKI’s initrd. The kernel checks fs‑verity signatures against a trusted key baked into the EFI image, ensuring that the root filesystem hasn’t been altered. Any attempt to modify a file invalidates the hash, causing the system to refuse to boot or read the corrupted data.
6. The Major Benefit: TPM‑Based Passwordless Disk Unlocking
One of the most practical gains from sealed images is the ability to unlock the root disk without a password using the Trusted Platform Module (TPM). Because the boot chain is fully verified, the system can securely seal the disk encryption key to the exact measurements (PCRs) of the trusted boot process. If any boot component changes, the TPM won’t release the key, and the system will fall back to a password prompt. This provides strong protection against offline attacks while enabling automatic, unattended reboots. The Fedora team expects to enable this feature by default once the images exit testing.
7. How to Test the Pre‑Built Images
Ready‑to‑run disk images are available at the fedora-atomic-desktops-sealed repository on GitHub. You can download a raw disk image (e.g., for a VM or direct write to a USB drive) or use the OCI container image directly with bootc install. The instructions walk you through writing the image, booting it, and verifying the boot chain. Note that these are test images: the root account has no password and SSH is enabled by default for debugging. Do not use them on production systems.
8. Building Your Own Sealed Images
If you want to customize or rebuild sealed images, the same repository provides tooling and examples. The build process uses podman and buildah to create the container image, then bootc-image-builder or the sealed‑image‑builder script to produce the final disk image. You can modify the package set, kernel command line, or signing keys. The repository also includes scripts to sign systemd‑boot and the UKI with your own certificates for Secure Boot. This flexibility allows advanced users to tailor the sealed boot chain to their own trust requirements.
9. Important Caveats for Testing Images
These are experimental images, not production‑ready. The root account has no password set, and SSH is enabled—so anyone with network access can log in if they find the address. The UKI and systemd‑boot are signed, but not with Fedora’s official Secure Boot keys; you must enable MOK (Machine Owner Key) enrollment or disable Secure Boot to test them. Known issues are tracked in the repository’s Issues section. Report any new bugs there, and the Fedora team will route them to the appropriate upstream projects (bootc, composefs, systemd, etc.).
10. Where to Learn More: Talks and Documentation
For a deeper technical dive, check out the following resources:
• “Signed, Sealed, and Delivered” with UKIs and composefs (FOSDEM 2025)
• UKIs and composefs support for Bootable Containers (Devconf.cz 2025)
• UKI, composefs and remote attestation for Bootable Containers (ASG 2025)
• The composefs backend documentation in bootc. These presentations explain how the components interact and how sealed images enable advanced security features like remote attestation. Thanks to contributors from bootc, composefs, podman, systemd, and other projects who made this milestone possible.
These sealed images represent a significant step toward making Fedora Atomic Desktops both more secure and easier to manage. We encourage you to test them, provide feedback, and explore the possibilities of a fully verified boot chain. Your input helps shape the future of immutable, container‑based Linux desktops.