Zainium Dynamics
News
November 2, 2026

Security report: 2 November 2026

What we tested on an installed Zainium OS before the release, the exact results, and what is still open.

Before the release we tested an installed Zainium OS on real hardware, as root, with the new kernel and the new quantra-ramfs. Every number below comes from the scripts and logs linked at the end. Nothing here is a claim we did not measure.

The result

The audit script ran 52 scored checks: 51 passed, 1 failed, with 2 warnings that depend on the hardware or the firmware. The failure and the warnings are explained below.

What was tested and passed

A read-only system that root cannot unlock

  • /overlayer/syshub is mounted read-only with a new OverlayFS option, sealed. Writing to it fails with Read-only file system, and remounting it writable is refused for root too (EROFS).
  • /overlayer/zaisys (kernel and boot files) is a separate read-only mount. Root cannot write to it or remount it writable.
  • Changes to /overlayer/syshub/etc and /overlayer/syshub/var go to the user layer (zexlib/union), so configuration and service state keep working.
  • Software installed with zex shows up in the system view at once, without a reboot — also when the system had looked up that name before and found nothing.
  • The raw system disk is not reachable from the running system.

Every system file sealed with fs-verity

  • 36,899 of 36,899 files in the system view and 8 of 8 boot files are sealed.
  • Opening a sealed file for writing fails with Operation not permitted, as root too.

Kernel

  • Kernel lockdown is in integrity mode, and the LSMs lockdown, Yama, AppArmor, Landlock, IPE, IMA and EVM are active.
  • Module signatures are enforced: a module with its signature removed is refused (EPERM), a signed module with one changed byte is refused (EKEYREJECTED), the original loads.
  • IMA loads its policy at boot and measured 290 programs, modules and firmware files.
  • IPE runs its built-in policy zainium in enforcing mode and refuses loading a new kernel at run time (EACCES).
  • AppArmor: 176 profiles, 98 enforcing.

Hardening

  • kptr_restrict, dmesg_restrict, ptrace_scope, unprivileged_bpf_disabled, ASLR, protected symlinks, hardlinks, FIFOs and regular files, no core dumps of setuid programs, ICMP redirects off.
  • No TCP port open to the network, and the nftables firewall drops incoming connections by default.
  • Only the six known setuid programs in the base.

The failure

An extra setuid program, qemu-bridge-helper. It came with a QEMU package from another distribution that we installed only to run the tests in a virtual machine. It is not part of the Zainium base, and it goes away when that package is removed.

Fixed during the audit

The first audit run on this machine also failed the firewall: nftables.service used ProtectSystem=full, which makes systemd bind /usr read-only for the service — and Zainium OS has no /usr. The service now uses ProtectSystem=strict, which protects everything from / and does not need /usr. In the final run the firewall rule set is loaded and no service has failed. Other services with ProtectSystem=yes or full would hit the same problem; teaching systemd the Zainium layout is the lasting fix.

The warnings

  • Secure Boot is off. The test machine's firmware has no keys enrolled. Signing the boot loader with our own key, with the kernel and initramfs pinned by hash in the boot loader, is the next step.
  • No TPM2. The test machine has a TPM 1.2 chip. TPM2 features (sealed disk keys, measured boot into TPM2) need a TPM2 chip.

What we fixed while testing

The tests found real problems, and they are fixed in this release: the boot no longer stops behind the splash on an OverlayFS check, root can no longer remount the boot files writable, the boot no longer re-checks all system files on every start, mounted USB drives show up in the file manager, and /var no longer has to exist at the root.

Files