Fedora Atomic Desktops: A Deep Dive into Sealed Bootable Container Images

Welcome to the next step in secure Linux deployment! Fedora Atomic Desktops now offer sealed bootable container images for testing. These images bring a complete, verified boot chain from firmware to OS, leveraging modern security technologies. Below, we answer common questions about what they are, how they work, and how you can try them out. Use the anchor links to jump to specific topics.

What Exactly Are Sealed Bootable Container Images?

Sealed bootable container images are pre-built system images that include everything needed to boot and run a Fedora Atomic Desktop with a fully verified boot chain. This means that from the moment your computer powers on, each component—from the firmware to the operating system—is cryptographically checked to ensure it hasn't been tampered with. The images rely on Secure Boot, so they only work on systems booting via UEFI on x86_64 and aarch64 architectures. The key advantage is that you get a trusted computing environment out of the box, allowing features like passwordless disk unlocking via TPM in a secure manner. These are testing images, so they help developers and early adopters validate the technology before it becomes mainstream.

What Components Make Up These Images?

Each sealed image contains three core elements, all working together to create the verified boot chain:

• systemd-boot – A simple UEFI boot manager, signed for Secure Boot.
• Unified Kernel Image (UKI) – A single binary combining the Linux kernel, an initramfs (initrd), and the kernel command line, also signed.
• composefs repository – A filesystem repository with fs-verity enabled, managed by bootc. This ensures the root filesystem integrity.

All components are cryptographically signed with test keys (not Fedora's official keys), so they can be loaded with Secure Boot enabled. The composefs layer adds file-level verification, making it hard for attackers to modify system files without detection. This combination is what makes the boot process sealed.

How Does This Improve Security?

The primary security benefit is a verified boot chain that prevents unauthorized code from running during startup. By signing systemd-boot and the UKI, the system ensures only trusted binaries execute. With fs-verity on the composefs, the root filesystem is also checked for corruption or tampering. This trusted environment enables a major user-facing feature: passwordless disk unlocking with the TPM. When the TPM verifies the boot chain is intact, it can automatically release the disk encryption key, eliminating the need for a password at boot. This is both more convenient and potentially more secure, as the key isn't exposed to user interaction. The sealed nature also protects against offline attacks, where an adversary modifies disk contents.

How Can I Test These Images?

To test, visit the fedora-atomic-desktops-sealed GitHub repository. There you'll find instructions for downloading pre-built container and disk images, as well as how to build your own custom images. The repo also lists known issues and a place to report new bugs. Please note these are testing images: the root account has no password set, and SSH is enabled by default for debugging. They are signed with test keys, not Fedora's official keys, so do not use them in production or on any machine where security is critical. Your feedback is invaluable—it helps shape the final, secure implementation.

Where Can I Learn More About the Technology?

If you want to dive deeper into how sealed images work—how bootable containers, UKIs, and composefs combine to create a verified boot chain—check out these resources:

• FOSDEM 2025 presentation: “Signed, Sealed, and Delivered” by Allison and Timothée.
• Devconf.cz 2025 talk: “UKIs and composefs support for Bootable Containers” by Timothée.
• ASG 2025 session: “UKI, composefs and remote attestation for Bootable Containers” by Pragyan, Vitaly, and Timothée.
• bootc documentation on composefs backend.

These presentations and documents explain the technical details of the signing, verification, and integration among systemd, bootc, podman, and other projects.

Who Made This Possible?

This work is the result of collaboration across multiple open-source projects. Key contributors come from (but are not limited to):

• bootc and bcvk
• composefs and composefs-rs
• chunkah
• podman and buildah
• systemd

Their combined efforts have produced a cohesive sealed boot experience. Thanks to everyone who contributed code, documentation, and testing. If you'd like to get involved, check out the GitHub repositories and join the community—your help is welcome!