Accelerat Bunkers
Root FS Integrity and Encryption¶
Root filesystem integrity is part of the Extended Chain of Trust (ECoT) and ensures that every file on the Bunker OS root filesystem is cryptographically authenticated at access time. This extends the CoT — which already covers the bootloader, ATF, OP-TEE, hypervisor, and kernel — all the way to userspace binaries and configuration files. The same approach can be applied to Open World.
ECoT is enabled by default in production-flavour BCA reference builds.
Underlying Technologies¶
The root filesystem protection in BCA is built on two complementary technologies:
- composefs
A FUSE-backed overlay filesystem that stores the directory structure and per-file expected hashes in a single signed image file (the “composefs image”) rather than in the individual files themselves. At runtime, composefs reconstructs the filesystem view from the backing OSTree content-addressed store and the image metadata.
- fsverity
A Linux kernel feature (
fs/verity) that enables on-access Merkle-tree verification of file contents. When fsverity is enabled on a file, any read that yields data inconsistent with the stored hash causes an I/O error. composefs uses fsverity hashes to detect tampering of individual files in the OSTree store.
The composefs image itself is also protected by fsverity, and its expected fsverity hash is signed and embedded as OSTree commit metadata. The corresponding public key lives in the initial ramdisk, which is itself inside the signed kernel FIT image. This effectively anchors the root filesystem authentication to the same key hierarchy used for the boot chain.
The Volatile /etc Directory¶
With composefs active, the root filesystem is mounted read-only and the overlay on /etc is volatile: any runtime changes to /etc are kept only in memory and are lost on reboot. This is intentional and is a critical security property. An attacker who gains root access to a running system can make changes to /etc, but those changes vanish on the next boot. More importantly, it prevents persistence through mechanisms such as modified systemd unit files or corrupted PAM configuration.
The general principle is to make the system as stateless as possible. Files that legitimately need to persist across reboots — such as SSH host keys or device-specific runtime configuration — should be stored under /var and the system reconfigured to read them from there. For example, SSH host keys can be stored under /var/rootdirs/etc/ssh/ by configuring HostKey directives in sshd_config:
# /etc/ssh/sshd_config — redirect host keys to persistent location
HostKey /var/rootdirs/etc/ssh/ssh_host_rsa_key
HostKey /var/rootdirs/etc/ssh/ssh_host_ecdsa_key
HostKey /var/rootdirs/etc/ssh/ssh_host_ed25519_key
With the required directory created at boot by a systemd-tmpfiles entry:
# /usr/lib/tmpfiles.d/persist-sshd-keys.conf
d /var/rootdirs/etc 0755 root root -
d /var/rootdirs/etc/ssh 0755 root root -
Executable scripts and files whose paths are read by services that interpret them as executable must never be made persistent, as they could become an attack vector that compromises the Secure Boot Chain of Trust.
Enabling Root Filesystem Protection in a Custom Build¶
Root filesystem protection is activated at build time by using the bca-signed-full BitBake class. The first boot after installing an ECoT image takes several minutes as the kernel enables fsverity on all files in the OSTree repository:
Enabling fsverity on the ostree repository - this may take a few minutes.
Progress: [==================================================] (11801/11801)
Enabling fsverity took 163 seconds.
Subsequent boots are not affected. Upgrading from BCoT to ECoT in the field requires a transitional image; refer to the RDFM in-field upgrade documentation in Ship OTA Updates.
Data Partition Encryption¶
For Bunker OS, application data is stored on a separate /var/data partition that is encrypted at rest as described in TrustZone and Encryption. The root filesystem and the data partition are therefore protected by two complementary mechanisms: composefs/fsverity for the immutable OS image, and dm-crypt for mutable user data.
For Open World, the same separation applies. The Open World rootfs can be built as a read-only, ECoT-protected image. The Open World data partition is separate and encrypted using a key that Bunker OS provisions on behalf of Open World via Turmux.