carlos / platform Public

| Prior finding | Disposition at 251e4d3c | |---|---| | R9-1 | Resolved. ProtectControlGroups=yes covers all tenant roles and the probe; §8.5 requires a refused cgroup-control write. | | R9-2 | Resolved for the reported restore-drill exposure. /var/cache and /var/lib are hidden (§§4.1, 8.5). | | R8-1 | Resolved. Wake refreshes the committed row before Acquire; migration reloads routing before releasing admission (§§6.8, 8.2). | | R5-2 | Resolved. Downgrade checks every row’s paths regardless of flags; unflagging nested rows is refused (§8.2). | | R5-3 | Resolved. Directory, socket, unit and slice names use the bounded InstanceID (§§3.1, 5.3). | | R2-4 | Resolved. Blocking seed execution and RemainAfterExit=yes retain identity and results through capture (§§4.2, 5.3). | | R2-5 | Resolved. Completion requires terminal state and cgroup emptiness; uncertain stops retain replication and the lease (§§6.3, 6.5). | | R2-7 | Resolved. Recovery derives both endpoints from the journal’s direction, completes that transaction, then converges to current intent (§8.2). | | R2-9 | Resolved. Flat minting, explicit reversal and downgrade guards cover the reported failures (§§8.1–8.2). | | R2-14 | Resolved at spec level. The IPv6 exception is explicit, bounded, rechecked and reported (§8.5). | | R1-4 | Resolved. Completion is independent of log EOF; blocking observations remain outside the activator mutex (§§6.4–6.7). | | R1-5 | Resolved. Preparation, execution budget, cancellation, result retention and termination-before-cleanup are specified (§§6.1–6.5). | | R1-8 | Resolved under the recorded decision. Shared tier limits remain; per-service OOM families are an explicit difference (§4.3). | | R1-12 | Resolved. Consumer fences and bidirectional recovery cover interrupted migration (§8.2). | | R1-13 | Resolved. Reverse recovery and completed-reversal downgrade guards address the reported defects (§8.2). | | R1-15 | Resolved for the reported PID/IMDS defects. No unsafe fallback remains; the behavioural gate is specified (§8.5). | | R1-18 | Resolved under the recorded ruling. Remote operations and reporting are specified; the foreign repair residual remains explicitly accepted (§§8.3–8.4). |

R10-1 — P1 — §§4.1, 8.5, 9: Isolated tenants can read the platform relay’s region master.

Retain §5.4’s process-authenticated control service. Extend the filesystem boundary to platform credential inputs.

The tenant template leaves /etc/carlos visible. ProtectSystem=strict makes that directory read-only; it does not prevent reading its files. systemd execution semantics.

The existing relay unit runs as carlos:carlos. Its masters reader opens /etc/carlos/relay-masters directly. The relay design specifies root:carlos, mode 0640, so every isolated tenant’s Group=carlos grants the same read.

On a box armed according to that contract, a tenant can therefore read and exfiltrate the region master. This exposes the secret from which the relay derives each app’s authentication key, including other accounts’ keys.

The probe can pass throughout. The new §9 audit inventories writable directories, so it misses a root-written credential that a platform process only reads.

Correction: hide /etc/carlos from all three tenant templates and the probe. Extend §9’s audit to credential inputs, including the relay masters file and supported alternate locations. Require a behavioural check that a tenant cannot read a fixture master staged with the relay’s actual ownership and permissions.

Verdict: request changes.