We are excited to announce the availability of sealed bootable container images for Fedora Atomic Desktops. These images are now ready for testing, giving you a chance to explore a fully verified boot chain—from firmware to the operating system’s composefs image. In this Q&A, we break down what these images are, how they work, and how you can test them safely. Learn what makes them unique or jump straight to testing instructions.
1. What exactly are sealed bootable container images?
Sealed bootable container images bundle every component needed to create a secure, verified boot chain. This includes the firmware layer (via Secure Boot), the bootloader (systemd-boot), a Unified Kernel Image (UKI) containing the Linux kernel, initrd, and kernel command line, and a composefs repository with fs-verity enabled, managed by bootc. These components work together to ensure that each stage of the boot process is cryptographically verified before proceeding. Currently, this implementation supports UEFI-based systems on x86_64 and aarch64 architectures. The UKI and systemd-boot are signed for Secure Boot, though these test images use non-official Fedora signing keys.
2. How do these images ensure a verified boot chain?
The boot chain is verified through a sequence of signed components. First, Secure Boot verifies the firmware, which then checks the signature of systemd-boot. Systemd-boot in turn validates the UKI before executing it. Inside the UKI, the kernel loads and uses composefs with fs-verity to cryptographically verify the integrity of the root filesystem. This layered approach means that any tampering—from the bootloader to the filesystem—can be detected and blocked. The integration of bootc manages the composefs repository, ensuring that the entire operating system snapshot is authenticated before the system becomes operational.
3. What are the main benefits of sealed images?
The most immediate benefit is the ability to enable passwordless disk unlocking using the TPM (Trusted Platform Module) in a way that remains reasonably secure by default. Since the boot chain is fully verified, the system can trust that the TPM measurements accurately reflect a known, good state. This eliminates the need for manual password entry for encrypted disks while still providing strong security. Additionally, sealed images enhance overall system integrity and reduce the attack surface for firmware-level exploits. These benefits are foundational for advanced use cases like remote attestation and more secure containerized desktop environments.
4. How can I test these pre-built images?
To test the sealed images, visit the dedicated GitHub repository for Fedora Atomic Desktops Sealed. There you will find pre-built container images and disk images, along with step-by-step instructions for both trying them directly and building your own customized versions. The repository also lists known issues and provides a venue to report new findings. We welcome all testing and feedback—please open issues on that repository, and we will route them to the appropriate upstream projects as needed.
5. What precautions should I take when testing these images?
These are testing images—do not use them in production. By default, the root account has no password set, and SSH daemon is enabled to ease debugging. While the UKI and systemd-boot are signed for Secure Boot, they are not signed with official Fedora keys, so the trust model is limited to controlled test environments. Ensure that you test on non-critical hardware or virtual machines. After testing, consider resetting the TPM if you used TPM-backed disk unlocking, and always review the known issues list before deployment. Treat these images as you would any early-stage preview.
6. Where can I find more detailed information about the technology?
Several presentations and documents explain the inner workings of sealed images. Recordings from FOSDEM 2025 (titled “Signed, Sealed, and Delivered”) by Allison and Timothée, Devconf.cz 2025 by Timothée, and ASG 2025 by Pragyan, Vitaly, and Timothée all cover the integration of UKIs, composefs, and bootable containers. Additionally, the composefs backend documentation in bootc provides technical details on how filesystem verification works. These resources dive deep into the signature chain, remote attestation, and systemd integration.
7. Who made this possible?
This work is the result of contributions from many individuals and projects. Notable contributors come from bootc & bcvk, composefs & composefs-rs, chunkah, podman & buildah, and systemd. The collaborative effort ensures that sealed bootable container images integrate seamlessly with the broader container and Linux ecosystem. While this list is non-exhaustive, it highlights the key upstream projects that have laid the groundwork for secure, container-based desktops.