Designing Dual-Source Runtime Attestation for Linux

Linux services are often checked through the same manager that applied their configuration. That is useful operational data, but it is not an independent observation. A service manager can report what it tried to set while the kernel exposes what is active for the running process. Comparing both views can reveal a configuration error, unsupported directive, race, or later mutation.

The proposed OpenFactory design calls this a dual-source observation. It is deliberately narrower than the phrase “proves the machine is secure.” The result would be evidence about a defined set of properties at a defined time, produced inside a stated trust boundary.

Compare intent with live state

A collector could query systemd for the requested setting and the corresponding kernel interface for the live value. The comparison must normalize units and account for inheritance, defaults, container boundaries, kernel version differences, and values that cannot be observed reliably.

A difference is not automatically an attack. It can result from unit inheritance, an unsupported kernel feature, collection timing, or a legitimate operator change. The report should preserve the raw values, collection method, timestamps, software versions, and the normalization rule so a reviewer can reproduce the decision.

Define the trust chain before signing anything

A signature answers “which key signed these bytes?” It does not answer whether the collector was honest, the key was protected, the expected policy was correct, or the report is fresh. A release design therefore needs an explicit chain:

1. Bind a normalized recipe and build evidence to a stable artifact identifier.
2. Establish the identity and measured state of the collector before it receives or uses a reporting key.
3. Include a verifier-issued nonce or another replay-resistant freshness mechanism in every requested report.
4. Sign canonical bytes and publish the algorithm, key identifier, certificate chain, and revocation status with the result.
5. Preserve both observations and the comparison rule, not only a green or red summary.

TPM sealing and measured boot may become parts of that design, but they are not magic. A verifier still needs reference measurements, enrollment policy, key rotation, revocation, recovery behavior, and a clear answer for hardware without a usable TPM.

Failure must be visible

An absent report is not a passing report. The interface should distinguish at least these states: match, mismatch, unsupported, collection error, invalid signature, stale report, unenrolled device, and missing report. “Unknown” must remain unknown instead of being folded into success.

The same rule applies to dashboards. A timeline can help an operator investigate, but the product must expose report age, scope, collector version, policy revision, and validation status. Color alone is not enough, and a historical green result must not describe the current machine after its freshness window expires.

What the release test must demonstrate

The feature should remain labeled “in development” until an end-to-end test suite proves the following behavior on every supported target:

• Deliberate systemd/kernel mismatches are detected and explained.
• Replayed, altered, expired, and incorrectly signed reports fail.
• Missing hardware or unsupported observations produce explicit unknown states.
• Key rotation and revocation do not erase the verifiability of retained evidence.
• Collection overhead and report volume stay within documented limits.
• Accessible console views expose the same facts as the raw report.

Security and compliance language needs a separate accountable review. The implementation may provide evidence relevant to a control, but it cannot certify an organization or deployment by itself. Operators and assessors decide whether the evidence is sufficient for their actual obligations and risk model.

Current OpenFactory boundary

OpenFactory currently exposes build artifact hashes, hash-bound CycloneDX records, fleet drift-report ingestion, and an Integrity Center timeline in supported paths. Those pieces are foundations, not the full attestation design. Confirm the artifacts and fresh reports produced by your own build before depending on them.

The maintained status page records this boundary and will stay outside search indexing while the cryptographic runtime layer lacks production evidence. When the design is implemented, the first release note should link to its protocol, supported matrix, test evidence, limitations, security review, and an operator verification procedure.