Runtime Attestation on OpenFactory

Most Linux fleets monitor themselves the way a student grades their own homework: ask systemd whether the policy is in force, record what systemd says, move on. That works until it doesn't. systemd is a userspace orchestrator. It configures the kernel; it does not verify that the kernel actually enforced the configuration. A kernel bug, a race condition, or a deliberate rootkit can make the kernel's real state diverge from what systemd believes it set — and that divergence is invisible to single-source monitoring.

Runtime attestation on OpenFactory closes that gap. An agent running inside each deployed VM independently queries both systemd and the kernel for the same security-relevant state, then writes a paired report. Matches are evidence; mismatches are findings. Every report is signed with a key sealed to the same TPM PCR set the boot chain extended, so a tampered runtime cannot quietly produce a clean report.

Why runtime attestation on OpenFactory exists

The pitch for "tamper-evident compute" sounds great in a sales deck. In practice, an auditor doesn't want a deck — they want evidence. 21 CFR Part 11 (the FDA's rule for electronic records and signatures in regulated medical and pharmaceutical systems) and DORA (the EU's Digital Operational Resilience Act for financial services) both require operators to prove that security controls are enforced, not merely configured. A configured control with no proof of enforcement is, to a regulator, a control that is not in force.

That distinction breaks single-source monitoring. If systemd reports a service is running with NoNewPrivileges=true, the monitoring system records "no new privileges" and moves on. If a kernel module disables that flag at runtime, systemctl show still says NoNewPrivileges=true — because systemd is reading from its own configuration, not from /proc/PID/status. The orchestrator marks its own homework. That's the failure mode runtime attestation on OpenFactory is built to prevent.

The dual-source verification model

OpenFactory layers attestation across fourteen verification levels (V1–V14). The early levels cover what you booted; the later levels cover what is actually running.

V1–V3 — signed-build verification (live today). Every OpenFactory ISO ships with a signed manifest. Each file's hash is recorded at build time, the manifest is chained into measured boot, and dm-verity enforces the chain at runtime so a modified base image fails to mount. This is the same chain that already powers the tamper-evident compute page on the site — runtime attestation builds directly on top of it.

V4–V14 — live-runtime kernel + systemd cross-check (rolling out). Periodic paired-observation reports across six domains:

• Resource limits. systemd MemoryMax, CPUQuota, TasksMax against kernel memory.max, cpu.max, pids.max.
• Security policies. systemd ProtectSystem, NoNewPrivileges, PrivateTmp against kernel mount flags, namespace state, and prctl(PR_GET_NO_NEW_PRIVS).
• Network state. systemd socket activation against kernel ss / netstat listeners.
• File permissions. systemd UMask, ReadOnlyPaths against actual mount options and file modes.
• SELinux / AppArmor. systemd security context against /proc/self/attr/current and /sys/fs/selinux/enforce.
• Capabilities. systemd CapabilityBoundingSet against /proc/PID/status CapBnd.

Each report is a flat JSON document. It is verbose by design: auditors don't want clever — they want grep-able. The agent writes it to /var/lib/openfactory/attestation/reports/ and the CTO GUI mirrors it to a dual-column comparison view: systemd on the left, kernel on the right, discrepancies in red with an English-language explanation of what the mismatch means and its security implication.

How it chains end to end

The full chain runs from the build machine to the running VM:

1. Build time. OpenFactory generates the ISO, computes per-file hashes, and signs a manifest with a build_id. The manifest is the seed for everything downstream.
2. Boot. dm-verity verifies the base image against the manifest. The TPM extends PCRs as each layer loads. Boot-time attestation is anchored to a TPM quote referencing the build ID.
3. Runtime. A 5-minute systemd timer triggers the dual-attestation agent. The agent queries systemd for expected state, queries the kernel for actual state, and writes a paired JSON report.
4. Signing. The report is signed with a key sealed to the same PCR set the boot chain extended. A tampered runtime cannot produce a valid signature.
5. Surface. Reports stream to the CTO GUI and land in object storage for the audit trail. Discrepancies trigger alerts.

Enabling it on a recipe

Runtime attestation is opt-in. Most fleets don't need it; the ones that do need it across every node. Add dual-attestation to your recipe's feature list and OpenFactory installs the agent and configures the timer:

{
  "name": "gxp-medtech-station",
  "base_image": "ubuntu-24.04",
  "features": [
    "dm-verity-verification",
    "dual-attestation",
    "gxp-ssh-hardening",
    "auditd"
  ]
}

That's it. The hook installs a Python agent at /opt/openfactory/attestation-agent/, sets up the systemd timer, and seals the signing key to the boot chain. First report writes within 5 minutes.

What this is not

Runtime attestation on OpenFactory is not intrusion detection. It does not look for known-bad patterns and it does not try to fingerprint malware. It catches a much narrower failure mode: policy that is configured but not enforced. That's a different problem from "an attacker is on the box," and the evidence it produces is for auditors, not SOC analysts.

It also is not a replacement for monitoring. You still need metrics, logs, and alerting. What runtime attestation adds is the one thing those tools structurally cannot provide: signed, paired evidence that the orchestrator and the kernel agree on the live state of the system.

Where to next

If you're scoping an FDA-validated medical workstation, a DORA audit for a trading platform, or a defense fleet that needs to answer the "prove enforcement" question, the Runtime Attestation reference page has the full FAQ and the recipe-side configuration; the Tamper-Evident Compute page covers the boot-chain foundation runtime attestation builds on; and the Enterprise & GxP page covers fleet-scale deployment.