Fedora Atomic Desktops now offer sealed bootable container images for testing. These images create a fully verified boot chain from firmware to the operating system, leveraging Secure Boot and UEFI on x86_64 and aarch64. Below, we answer common questions about what these images are, how they work, and how you can test them yourself.
What exactly are sealed bootable container images?
Sealed bootable container images contain all components needed for a verified boot chain, ensuring every stage from firmware to the OS is cryptographically signed and verified. This chain uses Secure Boot and includes:
- systemd-boot as the bootloader
- A Unified Kernel Image (UKI) that bundles the Linux kernel, initrd, and kernel command line
- A composefs repository with fs-verity enabled, managed by bootc
Both systemd-boot and the UKI are signed for Secure Boot. Note that these test images use non-official signing keys, so they are not production-ready. The primary benefit is enabling passwordless disk unlocking via TPM in a reasonably secure manner by default.
How can I test these sealed images?
To test the sealed bootable container images, head over to the Fedora Atomic Desktops Sealed repository on GitHub. There you’ll find pre-built container and disk images along with instructions to build your own. Before you begin, be aware of these testing-specific warnings:
- The root account has no password set.
- sshd is enabled by default to simplify debugging.
- The UKI and systemd-boot are signed, but not with official Fedora keys.
Please do not use these images in production. For feedback or issue reporting, use the same repository’s issue tracker. Known issues are listed there, and we’ll redirect any relevant reports to the appropriate upstream projects.
What benefits do sealed images bring? For example, TPM-based unlocking?
The most direct improvement from sealed bootable images is the ability to securely unlock disk encryption without entering a password, using the TPM (Trusted Platform Module). By verifying the entire boot chain (firmware, bootloader, kernel, and OS image), the system can trust that the environment is unmodified before releasing encryption keys to the TPM. This makes passwordless disk unlocking reasonably secure by default. In traditional setups, TPM unlocking might be less secure because an attacker could replace the kernel or initrd with a rogue version that captures the key. Sealed images prevent that by cryptographically binding the TPM policy to the measured boot components.
Who should test these images, and what precautions are needed?
These images are intended for developers, system administrators, and enthusiasts who want to experiment with verified boot chains and new security features in Fedora Atomic Desktops. Because they are test images, you should:
- Use them only on non-production systems.
- Expect that the root account has no password and SSH is open – ensure your network is isolated.
- Recognize that the Secure Boot signing keys are not official Fedora keys, so your UEFI firmware may need to enroll them manually.
If you encounter issues, check the known issues list (on the repository) and report new ones via the GitHub issue tracker. Your feedback helps improve these features for future Fedora releases.
Where can I learn more about the technical workings?
If you’re interested in understanding how sealed images bring together UKIs, composefs, and bootc to form a verified boot chain, several presentations and documents are available:
- “Signed, Sealed, and Delivered” with UKIs and composefs – Allison and Timothée at FOSDEM 2025.
- “UKIs and composefs support for Bootable Containers” – Timothée at Devconf.cz 2025.
- “UKI, composefs and remote attestation for Bootable Containers” – Pragyan, Vitaly, and Timothée at ASG 2025.
- composefs backend documentation in the bootc project itself.
These resources explain the signing, verification, and integration details that make sealed images work.
Who made this possible?
Many thanks to contributors from projects including bootc & bcvk, composefs & composefs-rs, chunkah, podman & buildah, and systemd. This is not an exhaustive list – several individuals across these communities collaborated to deliver sealed bootable containers. Their work ensures that each component (bootloader, kernel, filesystem) can be securely signed and verified, paving the way for trustworthy atomic desktop deployments.