Exploring Sealed Bootable Containers for Fedora Atomic Desktops

Get ready to test a major leap in security for Fedora Atomic Desktops! We're excited to unveil sealed bootable container images—a technology that creates a fully verified boot chain from firmware to operating system. This innovation leverages Secure Boot, systemd-boot, Unified Kernel Images (UKIs), and composefs with fs-verity, all managed by bootc. The result? A robust foundation for features like TPM-based passwordless disk unlocking. Below, we answer your top questions about these test images, how to try them, and what makes them tick. Jump to questions.

What exactly are sealed bootable container images?

Sealed bootable container images are pre-built packages that bundle every component needed to establish a cryptographically verified boot process. They ensure that from the moment your system powers on—starting with the firmware—every step is authenticated. This is achieved by including a signed systemd-boot bootloader, a Unified Kernel Image (UKI) that contains the Linux kernel, an initrd, and the kernel command line, and a composefs repository with fs-verity enabled. The entire chain relies on Secure Boot, so it only works with UEFI systems on x86_64 and aarch64 architectures. The test images use signing keys different from official Fedora keys, making them suitable for experimentation but not production.

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

How do sealed bootable container images work to create a verified boot chain?

These images implement a layered security approach. First, systemd-boot acts as the initial bootloader, and it is signed for Secure Boot so the firmware can verify its integrity. The bootloader then loads the UKI, which is also signed—this UKI encapsulates the kernel, initial RAM disk, and command line into a single, verifiable artifact. After the kernel boots, it mounts a composefs image that uses fs-verity to check file integrity on every read. The composefs repository is managed by bootc, ensuring atomic updates and rollbacks. By combining signed boot components with filesystem-level verification, the system guarantees that only authorized code executes, preventing tampering from firmware up to the OS.

What are the key components involved in a sealed image?

The three core components are:

systemd-boot – a lightweight UEFI boot manager that is signed to satisfy Secure Boot requirements.
Unified Kernel Image (UKI) – a single binary that merges the kernel, initrd, and kernel command line, all cryptographically signed.
composefs repository – a filesystem image with fs-verity enabled, providing per-file integrity checks. This image is managed by bootc for container-based updates.

Both systemd-boot and the UKI are signed using test keys (not official Fedora keys), so they are intended for testing only. The combination ensures that every layer of the boot process can be verified, from firmware to the root filesystem.

What direct benefits do users gain from sealed bootable containers?

The most immediate advantage is the ability to enable TPM-based passwordless disk unlocking in a reasonably secure way out of the box. Because the boot chain is fully measured and verified, the TPM can trust that the system is running authentic code before releasing the disk encryption key. This removes the need to type a passphrase at every boot while maintaining a strong security posture. Additionally, the verified boot chain protects against offline attacks—such as bootkits or modified initrds—and provides a solid foundation for remote attestation scenarios. In the longer term, these images simplify the deployment of immutable OSes that can be updated atomically via bootc, reducing maintenance overhead for administrators.

How can I test these sealed bootable container images?

To try the pre-built container and disk images, follow the instructions available on the GitHub repository. There you'll find steps to run the images or build your own. Be aware that these are test images: the root account has no password set, and SSH is enabled by default to ease debugging. Also, the UKI and systemd-boot are signed with test keys, so do not use them in production environments. We welcome feedback and bug reports! Check the known issues list before filing new ones, and we'll redirect as necessary to upstream projects like bootc, composefs, or systemd.

Where can I find more technical details about how sealed images work?

If you're hungry for deeper knowledge, several presentations and documentation resources explain the interplay of bootable containers, UKIs, and composefs. Key sources include:

“Signed, Sealed, and Delivered” with UKIs and composefs by Allison and Timothée at FOSDEM 2025.
“UKIs and composefs support for Bootable Containers” by Timothée at Devconf.cz 2025.
“UKI, composefs and remote attestation for Bootable Containers” by Pragyan, Vitaly, and Timothée at ASG 2025.
The composefs backend documentation in the bootc project.

These cover everything from the high-level architecture to implementation details, including remote attestation. Special thanks to contributors from bootc, composefs, chunkah, podman, buildah, and systemd for making this possible.

What security considerations should I be aware of for these test images?

Since these are test images, there are important caveats. The root account has no password, and SSH is enabled by default—fine for debugging but risky in live environments. More critically, the Secure Boot signatures use test keys, not the official Fedora keys, so the images cannot be considered production-grade. Additionally, because the boot chain is sealed, any change to the UKI or composefs will break verification; updates must be done via bootc atomic operations. While the TPM passwordless unlocking is more secure than plain passphrase skipping, it is only as strong as the trust chain's measurement and the TPM hardware itself. For now, use these images only on non-critical systems to validate the concept and provide feedback to developers.

Tags: