We are thrilled to introduce a significant advancement for Fedora Atomic Desktops: sealed bootable container images now available for testing. These images create a fully verified boot chain from firmware to operating system, leveraging Secure Boot on UEFI systems (x86_64 & aarch64). This innovation not only enhances security but also sets the stage for convenient features like passwordless disk unlocking via TPM. Below, we answer key questions about what these images are, how they work, and how you can participate in testing.
What exactly are sealed bootable container images?
Sealed bootable container images are comprehensive bootable artifacts that contain every component needed for a verified and trusted startup sequence. Unlike traditional bootable media, these images bundle together a bootloader (systemd-boot), a Unified Kernel Image (UKI) that integrates the Linux kernel, initrd, and kernel command line, and a composefs repository with fs-verity enabled, all managed by bootc. The entire chain is cryptographically signed for Secure Boot, ensuring that only authorized code executes from the firmware through to the OS. This “sealed” property means that any tampering with components can be detected, providing a robust foundation for security-sensitive deployments.
How does the sealed boot chain function?
The secure boot chain begins with UEFI Secure Boot verifying the systemd-boot bootloader, which is signed with a test certificate. The bootloader then loads and verifies the Unified Kernel Image (UKI), also signed. Once the kernel is running, it mounts the composefs filesystem using fs-verity to validate every file against cryptographic hashes. This layered verification ensures that no unauthorized modifications have occurred at any stage. The configuration and signing keys are managed separately through bootc, which also handles updates in a transactionally safe manner. The result is a boot process where integrity is enforced from hardware to userspace.
What are the main benefits of using sealed images?
The primary advantage is achieving a verified boot chain that prevents unauthorized code from running, even if an attacker gains physical access. A direct consequence is the ability to enable passwordless disk unlocking using the Trusted Platform Module (TPM) without compromising security. The TPM can release the disk decryption key only if the measured boot state matches expected values, eliminating the need for user input while maintaining strong protection. Additionally, sealed images simplify the management of operating system deployments, as the entire image is a single, self-contained artifact that can be validated before provisioning. This makes them ideal for edge devices, kiosks, and any scenario requiring high integrity.
How can I test these sealed images?
Testing is straightforward: head over to the GitHub repository for pre-built container and disk images along with step-by-step instructions. You can also build your own custom images using the provided tooling. We encourage you to try them on UEFI systems (x86_64 or aarch64) and report any issues or feedback. Please note these are test images—they are signed with test certificates, not official Fedora keys. The root account has no password set, and SSH is enabled by default for debugging convenience. Do not use them in production environments. For known issues and bug reporting, refer to the same repository; we will redirect relevant reports to upstream projects as needed.
What should I be aware of before testing?
As these are experimental images, several caveats apply: the signing keys are not the official Fedora keys, so your system may not boot if Secure Boot is set to enforce only Microsoft-signed binaries without adding the test CA. The default configuration leaves the root password empty and SSH enabled, making the system vulnerable to local attacks—use only in isolated test networks. Additionally, the boot chain relies on systemd-boot and UKI; firmware compatibility issues may arise on some hardware. Always back up your data before testing. We are actively working towards using official Fedora keys and hardening defaults for production releases.
Where can I find more details about the technology behind sealed images?
Deep dives are available from recent conferences: watch “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, and “UKI, composefs and remote attestation for Bootable Containers” by Pragyan, Vitaly, and Timothée at ASG 2025. For technical documentation, see the composefs backend documentation in bootc. We thank contributors from bootc, composefs, chunkah, podman, buildah, systemd, and many other projects for making this possible.