We are excited to announce the availability of sealed bootable container images for testing within the Fedora Atomic Desktops ecosystem. These images represent a significant step forward in security and convenience, enabling a fully verified boot chain from firmware through the operating system. By integrating Secure Boot, Unified Kernel Images (UKIs), and composefs with fs-verity, the sealed images provide a trustworthy foundation that unlocks new capabilities, such as passwordless disk unlocking via the TPM. Below, we answer common questions about how these images work, what they contain, and how you can start testing them today.
What are sealed bootable container images?
Sealed bootable container images are pre-built container images that contain all necessary components to create a fully verified boot chain. This means every step from the initial firmware to the final composefs image is cryptographically signed and verified. The verification relies on Secure Boot, which requires UEFI firmware on x86_64 and aarch64 architectures. By packaging everything in a sealed format, these images ensure that only authentic, untampered software runs during the boot process. This approach not only enhances security but also paves the way for features like passwordless disk encryption unlocking using the TPM, which becomes reasonably secure by default with a verified boot path.
What are the key components of a sealed boot image?
A sealed bootable container image is composed of three main parts:
- systemd-boot as the bootloader, which is signed for Secure Boot.
- A Unified Kernel Image (UKI) that bundles the Linux kernel, an initrd, and the kernel command line into a single, signed EFI executable.
- A composefs repository with fs-verity enabled, which is managed by the bootc tool. This provides filesystem metadata integrity.
Both systemd-boot and the UKI are signed using test keys (not Fedora’s official keys) for these early testing images. This combination ensures that every layer of the boot process can be verified cryptographically.
What are the main benefits of sealed bootable images?
The primary benefit of sealed bootable images is the ability to establish a robust, verified boot chain without manual intervention. With this foundation, we can enable passwordless disk unlocking using the TPM. Since the boot components are signed and verified, the system can trust that it is running authentic software before presenting encryption keys to the TPM. This makes automatic disk unlocking both convenient and reasonably secure by default. Additionally, the sealed nature prevents unauthorized modifications to the boot chain, protecting against certain classes of attacks such as bootkits or firmware tampering. For users and administrators, it simplifies the process of maintaining a trustworthy system, especially in automated or remote environments.
How can I test these sealed bootable container images?
To start testing, follow the detailed instructions available on the fedora-atomic-desktops-sealed GitHub repository. There you will find pre-built container images and disk images that you can deploy on UEFI systems. The repository also includes guidance on how to build custom sealed images if you wish to modify the components. Feedback and bug reports are highly welcome. Please check the current list of known issues before reporting new problems. The development team will redirect relevant issues to the appropriate upstream projects.
What should I be aware of when testing these images?
These are testing images and are not suitable for production use. Important caveats include:
- The root account has no password set, and SSH daemon is enabled by default to facilitate debugging. This means immediate security risks if exposed to networks.
- The UKI and systemd-boot are signed with test keys, not official Fedora keys. Consequently, your system might display warnings or require manual acceptance of the signing authority.
- Do not deploy these images on production machines or systems containing sensitive data.
Always test in isolated, non-critical environments. For more details on the specific security implications, refer to the repository’s README.
Where can I find more details about how sealed images work?
For an in-depth understanding of the technology behind sealed bootable container images, we recommend the following resources:
- “Signed, Sealed, and Delivered” with UKIs and composefs – Presentation by Allison and Timothée at FOSDEM 2025.
- UKIs and composefs support for Bootable Containers – Talk by Timothée at Devconf.cz 2025.
- UKI, composefs and remote attestation for Bootable Containers – Panel by Pragyan, Vitaly, and Timothée at ASG 2025.
- The composefs backend documentation in bootc provides technical details on how the pieces fit together.
These resources explain how bootable containers, UKIs, and composefs collaborate to produce a verified boot chain.
Who contributed to making sealed bootable images possible?
This achievement is the result of collaborative work from numerous contributors across several open-source projects, including (but not limited to): bootc & bcvk, composefs & composefs-rs, chunkah, podman & buildah, and systemd. The integration of these tools and libraries enabled the creation of a sealed, verifiable boot path that is both practical and performant. We extend our sincere thanks to everyone who have invested time and expertise into this feature. Their efforts are helping to make Linux desktop and server systems more secure by default.