Fedora Atomic Desktops are stepping into a new era of security with sealed bootable container images. These images promise a fully verified boot chain, from firmware to operating system, leveraging Secure Boot and UEFI. Below, we answer common questions about this testing initiative, how it works, and how you can get involved.
What are sealed bootable container images for Fedora Atomic Desktops?
Sealed bootable container images are specialized test images that bundle every component needed to create a fully verified boot chain. This encompasses the firmware, bootloader, kernel, and the operating system image itself—all cryptographically signed and integrated into a container format. The goal is to ensure that every piece of software loaded during boot is authentic and untampered. These images rely on Secure Boot and therefore only support UEFI systems on x86_64 and aarch64 architectures. By sealing the entire boot process, they lay the groundwork for enhanced security features like TPM-based disk unlocking without requiring a password. It’s a major leap forward in making secure booting both practical and robust for everyday use.
How do these images create a verified boot chain?
The verified boot chain is achieved through a combination of three core components, each signed for Secure Boot. First, systemd-boot serves as the bootloader. Second, a Unified Kernel Image (UKI) bundles the Linux kernel, an initramfs (initrd), and the kernel command line into a single, signed EFI executable. Third, a composefs repository with fs-verity enabled—managed by bootc—holds the root filesystem. During boot, Secure Boot verifies the bootloader, which then verifies the UKI. The UKI, in turn, mounts composefs using fs-verity to check integrity at the file level. This chain ensures that each step is cryptographically validated, stopping any unauthorized modifications from executing. It’s a layered approach that builds trust from hardware all the way up to the OS.
What components are included in a sealed bootable image?
Each sealed bootable image contains three main pieces: systemd-boot (the UEFI bootloader), a Unified Kernel Image (UKI) (containing the Linux kernel, initrd, and kernel command line), and a composefs repository with fs-verity enabled, managed by bootc. Both systemd-boot and the UKI are individually signed for Secure Boot. Note that because these are test images, the signatures use test keys—not the official Fedora signing keys. This allows early experimentation without affecting production systems. The composefs layer integrates with bootc to provide a read-only, integrity-verified filesystem. Together, these components create a closed-loop verification process that secures every stage of the boot sequence, from the very first firmware handoff to the fully running operating system.
Why are these images considered "test" images, and what are the security implications?
These images are marked as test because they use non-official signing keys. The root account has no password set, and SSH is enabled by default to simplify debugging. This means anyone with physical or network access could potentially gain unauthorized access—so never deploy these images in production environments. The test nature allows developers and early adopters to validate functionality, report bugs, and shape the final implementation. While Secure Boot verification still works, the trust chain relies on test certificates, so the images are not suitable for security-sensitive scenarios. The project expects that future versions will use official Fedora keys, enabling safe production use. For now, they are a playground for testing the verified boot pipeline and TPM-based disk unlocking.
How can I test these sealed bootable images?
To test, visit the dedicated GitHub repository at github.com/travier/fedora-atomic-desktops-sealed. There you’ll find pre-built container and disk images, along with detailed instructions on how to run them. The guide covers both using the images directly and building your own custom versions. Since these are test images, be prepared for potential bugs and limited documentation. The project welcomes feedback—check the known issues list and report any new problems via the same repository. Issues may be redirected to upstream projects like bootc, systemd, or composefs. Remember, these images are not production-ready, so test them on isolated hardware or virtual machines to avoid disrupting your main system.
What is the main benefit of using sealed bootable images?
The primary benefit is the ability to enable passwordless disk unlocking using the TPM in a reasonably secure manner by default. With a sealed boot chain, the system can trust that the early boot components are genuine. This trust allows the TPM to release a decryption key for the root disk without requiring a user password. This improves both security—by protecting against cold boot attacks and physical theft—and user experience, as it eliminates the need to type a passphrase on every reboot. The combination of Secure Boot, UKI, and composefs ensures that the TPM only releases the key if the boot chain is verified. This feature is particularly valuable for servers, edge devices, and any system where automated, secure booting is desired without sacrificing integrity.
Where can I find more technical details about how this works?
For deeper understanding, several presentations and documentation are available. Start with the talk "Signed, Sealed, and Delivered with UKIs and composefs" by Allison and Timothée at FOSDEM 2025. Timothée also presented "UKIs and composefs support for Bootable Containers" at Devconf.cz 2025. A broader discussion on "UKI, composefs and remote attestation for Bootable Containers" was given by Pragyan, Vitaly, and Timothée at ASG 2025. For hands-on details, see the composefs backend documentation in bootc. These resources explain the underlying technology, the integration of each component, and the overall design philosophy. They are excellent for developers and system administrators wanting to customize or extend the sealed boot approach.
Who contributed to making this possible?
This work is the result of contributions from many individuals and projects. Key projects include bootc & bcvk, composefs & composefs-rs, chunkah, podman & buildah, and systemd. While the list is non-exhaustive, these teams collaborated to integrate bootable containers, UKI, and composefs into a sealed boot chain. Thanks go to developers, testers, and community members who provided feedback and patches. Without their collective effort, the ability to test TPM-based passwordless disk unlocking with verified booting would not have reached this stage. The project encourages further contributions and testing to refine the implementation before it becomes a standard feature in Fedora Atomic Desktops.