Exploring Sealed Bootable Containers for Fedora Atomic Desktops

Fedora Atomic Desktops have taken a major step forward with the introduction of sealed bootable container images, now available for public testing. These images incorporate a fully verified boot chain, from firmware to the composefs image, leveraging Secure Boot on UEFI systems. This innovation paves the way for more secure and convenient features like passwordless disk unlocking via the TPM. Below, we answer key questions about these images and how to get involved.

What are sealed bootable container images and how do they work?

Sealed bootable container images are complete packages that contain every component required to establish a verified boot chain. This chain begins at the firmware level and extends up to the operating system’s composefs image. The mechanism relies on Secure Boot, meaning it only works on systems booting with UEFI on x86_64 and aarch64 architectures. By tying all boot stages together with cryptographic signatures, the images ensure that only authorized software runs during startup. This eliminates the possibility of tampered boot components going undetected, providing a hardened foundation for the operating system. The signing process uses test keys for now, but the architecture is set to support official Fedora keys in the future.

Exploring Sealed Bootable Containers for Fedora Atomic Desktops — Source: fedoramagazine.org

What components are included in these sealed images?

Each sealed image bundles three core components: systemd-boot as the bootloader, a Unified Kernel Image (UKI) that combines the Linux kernel, an initrd, and the kernel command line into a single signed file, and a composefs repository with fs-verity enabled, managed by bootc. Both systemd-boot and the UKI are signed for Secure Boot, though currently with test certificates. This combination creates a fully auditable boot path where each stage can be verified cryptographically. The composefs layer ensures that the root filesystem is also validated, preventing unauthorized modifications.

What is the main benefit of sealed bootable container images?

The most immediate advantage is the ability to enable passwordless disk unlocking using the TPM (Trusted Platform Module) with a reasonable level of security by default. Because the entire boot chain is verified, the TPM can securely release the disk encryption key only when the system boots with known, trusted components. This means users no longer need to enter a passphrase each time they start their machine, while still protecting data from unauthorized access. Beyond that, the sealed images lay groundwork for remote attestation—allowing a system to prove to a remote party that it booted with unmodified software, which is invaluable for secure cloud and edge deployments.

How can users test these sealed images?

To try out the sealed bootable container images, head over to the GitHub repository for pre-built container and disk images. The repository includes clear instructions for both using the provided images and building your own. Keep in mind that these are test images: the root account has no password set, and SSH is enabled by default to simplify debugging. Additionally, the UKI and systemd-boot are signed for Secure Boot but only with test keys—not the official Fedora signing keys. Therefore, do not use them in production environments. Feedback and bug reports are welcome via the same repository.

Are these test images safe for production use? Why or why not?

No, these test images are not safe for production. They are specifically designed for testing and debugging purposes. The default configuration has the root account without a password and SSH enabled, which would be a severe security risk in a live environment. Moreover, while Secure Boot works, the signatures come from test keys, not from Fedora’s official certificates. This means the boot chain lacks the full trust anchor that production systems require. The project recommends that users only deploy these images on dedicated test machines or virtual machines to evaluate the technology and provide feedback.

Where can I learn more about the technology behind sealed images?

For a deeper dive, several presentations and documents explain how sealed images integrate UKIs, composefs, and bootable containers. Key resources include Allison and Timothée’s talk “Signed, Sealed, and Delivered” at FOSDEM 2025, Timothée’s presentation at Devconf.cz 2025 on UKIs and composefs for bootable containers, and the ASC 2025 session by Pragyan, Vitaly, and Timothée on UKI, composefs, and remote attestation. Additionally, the composefs backend documentation in bootc provides technical details. These resources outline how the different projects—bootc, bcvk, composefs, chunkah, Podman, Buildah, and systemd—collaborated to make this verification chain a reality.

Tags: