Establish freshness-bound container identity and lifecycle security

Establish a deployment mechanism that binds accepted container identities to monitor-controlled freshness and derives child membership from an authorized parent transition, thereby preventing forged or stale container membership during confidential-container initialization and process creation.

Background

NACRE’s prototype accepts the process identifier and container identifier supplied through a cooperative launch path. This validates lifecycle plumbing but does not establish that identities are authentic, fresh, or non-replayable when the host operating system is malicious.

The target security argument requires the monitor to control identity freshness and to derive child membership only through authorized parent transitions. Without these mechanisms, a compromised Linux kernel could potentially forge or reuse process/container bindings.

References

The QEMU prototype accepts the pid and cid supplied along this cooperative launch path. It therefore validates lifecycle plumbing, not resistance to forged or stale membership. A deployment must bind accepted identities to monitor-controlled freshness and derive child membership from an authorized parent transition; \S\ref{sec:security} treats this as an open link in the current security argument.

— NACRE: Rethinking Confidential Containers through Native Architectural Support  (2609.03849 - Song et al., 3 Sep 2026) in Section 3, subsection “Container Initialization and Runtime Mediation,” subsection “Container initialization”

We have not run negative tests for wrong owner or cid, stale task bindings, role or permission changes, failed PEND transactions, or clear-before-reuse. Cross-container sharing, multicore agent entry, and attestation also remain unevaluated.

— NACRE: Rethinking Confidential Containers through Native Architectural Support  (2609.03849 - Song et al., 3 Sep 2026) in Section 7, subsection “RQ4: What Remains Open?”