design: tracking issue for §8.12 closure — Phase 3 privilege separation RFC #43

Tracking

docs/threat-model.md §8.12 documents a deliberate temporary non-goal:
in Phase 1, QuantumSSH executes authenticated users' commands under the
OS identity of the QuantumSSH service account, not under the authenticated
user's UID.

The closure condition from §8.12:

"Phase 3 privilege-separation being implemented and a follow-up RFC
superseding this entry and removing §8.12. Until both happen, this
remains a deliberate temporary non-goal."

This issue tracks that commitment. Without it, the promise has no tether
to the work queue.

Cross-references: RFC-0002, ADR-0016.

Current posture and its implications

• Every key in authorized_keys is operationally equivalent to OS-level
  access as the service account. Multi-tenant deployments are not supported.
• Audit logs record executing_uid = <service account UID> on every
  command-execution event — the gap is deliberately visible to log
  reviewers (§2.7).
• QuantumSSH Phase 1 is single-user by design: one operator, one key
  set, one account.

What the Phase 3 RFC must decide

1. Privilege separation model. Fork + setuid(2) after authentication
   (analogous to OpenSSH's privsep model)? A long-lived unprivileged
   monitor process? Something else?
2. Platform scope. Linux (setuid, seccomp-bpf, landlock),
   macOS (Sandbox.framework), BSDs (pledge/unveil). QuantumSSH's
   supported platform list is not yet formally defined — this RFC may
   need to define it as a prerequisite.
3. Post-auth sandbox. What is the minimal syscall set needed by the
   post-authentication worker process? A seccomp-bpf allowlist on
   Linux; the equivalent on other platforms.
4. State machine fork point. Where in the type-state transport machine
   (transport.rs) does the fork/setuid happen? It must be after
   authentication completes and before the first channel open is
   processed, without invalidating the invariants enforced by the
   Expect<Stage> types.
5. ADR-0016 compatibility. ADR-0016 defines the service account model
   (UID ≥ 1000, no login shell, no home directory). The privilege-separation
   RFC must either be compatible with ADR-0016 or formally supersede it
   per the ADR-0015 errata mechanism.

Acceptance criteria for closing this issue

1. A RFC is merged defining the privilege-separation model.
2. §8.12 is removed from docs/threat-model.md per the RFC's instructions.
3. ADR-0016 is annotated or superseded per ADR-0015.
4. CI includes a test demonstrating that post-auth command execution runs
   under the authenticated user's UID, not the service account's UID.