the-custodian/docs/changes/CUST-WP-0073/interactive-launch-r2/TARGET.md
codex 903616f2b7
All checks were successful
CI Smoke / host-smoke (push) Successful in 1s
CI Smoke / container-smoke (push) Successful in 10s
Reject generated-only commits / generated-commit-guard (push) Successful in 11s
Retain interactive isolation target and identity review
2026-10-19 14:47:02 +02:00

90 lines
6.3 KiB
Markdown

# Recommended target and provisioning source contract
Recommendation: workstation `bnt-lap001`, new WSL2 distribution
`custodian-codex`, Linux account `custodian-codex`, private home
`/home/custodian-codex`, project `/home/custodian-codex/work/the-custodian`,
desktop SSH alias `custodian-codex-workstation`. This names the proposed target;
it does not assert the distribution, account, SSH listener, or connection exists.
No infrastructure spend is proposed.
## Why this destination
| Option | Evidence and consequence |
| --- | --- |
| Another UID in current WSL distribution | Only `worsch` UID1000 currently exists. Windows drive is visible, operator `.codex` and `.kube` directories are mode755, and a container socket is visible. Directory permissions alone do not prove secret-file readability. A second UID alone cannot establish the necessary namespace, socket and Windows boundary. |
| Production `railiance01` | Prior metadata proves a running k3s server and admin kubeconfig mode0644; protected selector preflight and mode600 change remain outstanding. Attaching this assignment there adds production proximity and requires hardening/restart approval. |
| New workstation WSL2 distribution | WSL2 substrate is present. A clean filesystem and deliberately limited account avoid production placement and reuse of operator home/state. Windows shares, interop, shared mounts and network-reachable host control planes still require explicit denial proof. This is the recommended preparation target. |
Read-only `wsl.exe --list --verbose` succeeded after explicit filesystem sandbox
escalation; no distribution was started or modified. Inventory: Ubuntu-18.04
(WSL1, stopped), Ubuntu (WSL2, stopped), archlinux (WSL2, stopped), Ubuntu-24.04
(WSL2, running), Debian (WSL2, stopped). None is proven disposable or isolated.
Linux-side `virsh`, QEMU, virt-install and Podman were absent; `/dev/kvm` absent;
Docker and bwrap commands present. Command presence is not authorization or proof
of an isolated long-lived service. Do not reuse any stopped distribution.
The Linux metadata observation is timestamped in workstation-metadata.json.
Windows inventory was obtained on 2026-10-19 during this review. Source-only
contract is provisioning-contract.json; it is intentionally not a deployment
script and refuses readiness until the listed artifact/connection facts exist.
## Exact source-level work
1. Custodian/workstation owner adds a reviewed distribution recipe for the named
guest: pinned Ubuntu 24.04 rootfs SHA, resource limits, private distribution
backing storage owned by the operator, no imported operator filesystem or
private state. Do not export/import the current credential-bearing distro.
This is workstation configuration, outside railiance-infra's currently
declared two-server inventory; do not silently enroll it there.
2. In the guest recipe, disable Windows executable interop and automatic Windows
drive mounting, and prevent access to shared WSL/Docker mounts. Root-owned
boot/service policy must enforce this before agent startup. No Windows
executables, host drive, forwarded agent, Docker daemon socket or privileged
network control-plane endpoint may be reachable by the account. Verify the
effective namespace and network access, not merely configuration values.
3. Create the named account with its own group, password login locked, private
home/state, no sudo/admin/docker/lxd groups or delegation. Provision a clean
checkout and root-owned pinned Codex executable. Install only approved
dependency tools. Its login shell must resolve that executable, not the
operator's NVM installation. No credential helper/global operator Git config.
4. Configure a guest-only SSH service for that user: no root/password login,
agent forwarding, TCP forwarding or X11; transport and repository access
separately scoped. The desktop connects through an approved loopback-only
endpoint; actual free port and Windows/WSL reachability must be verified
before fixing the SSH alias. SSH stdio/session startup is required, so do
not impose a force-command that breaks app-server startup. Pin host identity.
5. Route SSH authentication via warden's catalog, and Codex inference login via
its actual credential owner. Neither is issued by this proposal. Install
account-scoped authentication only after approval; do not copy operator auth.
6. Operator adds the alias to the desktop connection list, saves the matching
repository project, checks native approval UI, and hands off THIS chat.
Record destination machine-ID digest/UID, external process identity and
original/destination chat association. The machine-ID must be fresh for the
new distribution; a duplicated image identity fails host binding.
Verification must include effective absence of `/mnt/c`, Windows executable
interop, shared `/mnt/wsl` control sockets, operator homes, SSH agents and admin
credentials, plus denied access to network-accessible Docker/host control planes.
WSL2 being available does not prove these conditions. Supervisor-owned canaries
can test denial without opening real credentials. The unchanged full assignment
admission requirements in README.md and the original CUST73 packet still apply.
Rollback: stop assignment work, disconnect destination in the desktop, retain
receipt and paused original chat; operator may stop the dedicated guest after
collecting evidence. Never unregister/delete the guest or silently resume tools
under the old operator identity. No production restart is part of this route.
Minimum operator decision, only once this source contract is reviewed: approve
creating `custodian-codex` as a new local WSL2 distribution on `bnt-lap001`, or
identify an already-approved isolated workstation guest to substitute. Rootfs
artifact and SSH port validation are implementation work, not reasons to ask
the user an open-ended target-design question.
## Probe correction
Revision 1 incorrectly rejected UID1000 globally. Revision 2 rejects root and
the originating pair `(4f615ffa89bf23a138468bad4a51ba074a4523f7b2dabd0322dc1458f092f0f6,
1000)`. A distinct host with UID1000 can pass the partial identity check; a new
UID on the same host can also pass. Neither is an admission result. Supervisor
identity must bind machine digest plus UID to the known SSH host identity and
actual chat; machine-ID alone is not a cryptographic host identity.