Exploring Fedora Atomic Desktops Sealed Bootable Containers: A Q&A Guide
Fedora Atomic Desktops have introduced sealed bootable container images for testing. These images integrate all necessary components to create a fully verified boot chain, leveraging Secure Boot and other technologies. This Q&A covers what they are, how to test them, their benefits, and where to learn more. Whether you're a developer, system administrator, or curious enthusiast, this guide provides clear, detailed answers to your questions.
What are sealed bootable container images?
Sealed bootable container images are pre-built system images that include every component required to establish a verified boot chain, from the firmware to the operating system's composefs image. They rely on Secure Boot, so they only work on systems booting with UEFI on x86_64 and aarch64 architectures. The key components inside these images are:
- systemd-boot as the bootloader, signed for Secure Boot.
- A Unified Kernel Image (UKI) containing the Linux kernel, an initrd, and the kernel command line, also signed.
- A composefs repository with fs-verity enabled, managed by bootc.
Because these are test images, the signatures use non-official Fedora keys. The sealed nature ensures the integrity of every boot step, making attacks like tampering with the kernel or initrd much harder.
How does the verified boot chain work in sealed images?
The boot chain starts with the UEFI firmware verifying the signed systemd-boot bootloader. This bootloader then loads and verifies the signed Unified Kernel Image (UKI), which bundles the kernel, initrd, and command line. Once the kernel starts, it uses fs-verity to validate the composefs image, ensuring the root filesystem hasn't been altered. The entire chain relies on Secure Boot hardware trust. The bootc tool manages the composefs repository, coordinating updates while maintaining integrity. This approach means that from power-on to login, every component is cryptographically verified, closing attack vectors that target boot-time components. The main practical benefit is enabling passwordless disk unlocking using the TPM in a reasonably secure way, as the boot state is attested before unlocking.
What are the main benefits of using sealed images?
The primary benefit is enhanced security through a fully verified boot chain. By signing the bootloader, kernel, and filesystem metadata, attackers cannot easily inject malicious code during boot. This trust foundation allows features like TPM-based disk unlocking without entering a password, because the system can prove it booted in a known good state. Additionally, sealed images simplify configuration management: the entire boot chain is defined in a single container image, making updates and rollbacks atomic. For desktop environments like Fedora Atomic Desktops, this means a more robust, tamper-resistant user experience. The technology also paves the way for remote attestation, where a system can prove its integrity to a network. While still experimental, these benefits are a major step toward production-ready secure boot containers.
How can I test these sealed images?
To test the sealed bootable container images, visit the fedora-atomic-desktops-sealed GitHub repository. There you'll find pre-built container and disk images along with instructions to try them or build your own. The process typically involves downloading a disk image, flashing it to a USB drive, and booting on a UEFI system (x86_64 or aarch64). You can also use container tools like podman or bootc to create custom sealed images. Be aware these are testing images: the root account has no password set, and SSH is enabled by default for debugging. Secure Boot signatures use test keys, not official Fedora keys, so you'll need to enroll them in your firmware. Report feedback or issues on the same GitHub repo; the team will redirect bugs to upstream projects as needed.
What should I be cautious about when testing?
These images are not production-ready. Key warnings include: the root account has no password and SSH is enabled, so any network access means the system is vulnerable. The boot components are signed with test keys, so Secure Boot will not trust them unless you manually enroll the test keys. Using these on a machine with sensitive data is strongly discouraged. Additionally, the boot chain relies on UEFI only; legacy BIOS systems are unsupported. Expect bugs—some known issues are listed in the GitHub repository. Testing should be done on dedicated hardware or virtual machines with backups. The team welcomes feedback but advises against using sealed images for daily work until they mature and receive official Fedora signing. If you encounter problems, report them with details about your hardware and boot logs.
Where can I learn more about the technical details?
Several presentations and documentation explain how sealed images work. Key resources include:
- “Signed, Sealed, and Delivered” with UKIs and composefs – a talk by Allison and Timothée at FOSDEM 2025.
- UKIs and composefs support for Bootable Containers – presented by Timothée at Devconf.cz 2025.
- UKI, composefs and remote attestation for Bootable Containers – from Pragyan, Vitaly, and Timothée at ASG 2025.
- composefs backend documentation in the bootc project.
These materials cover the integration of bootable containers, UKI, composefs, and Secure Boot, along with future plans like remote attestation. They are suitable for developers and system architects wanting to understand the underlying mechanisms.
Who contributed to making these images possible?
The sealed bootable container images are the result of collaborative work from multiple open-source projects. Contributors include (but are not limited to) teams from bootc & bcvk, composefs & composefs-rs, chunkah, podman & buildah, and systemd. Many individuals have dedicated time to integrate UKI signing, composefs verity, and bootc management. The Fedora Atomic Desktops team, especially Timothée Ravier, Allison Karlitskaya, and others, have spearheaded the testing initiative. This community-driven effort ensures that the technology is robust and aligned with upstream standards. For a full list of contributors, check the repositories and presentation acknowledgments.