Broker GetKey only checks the /tee-daemon/ prefix — any attested tenant can derive another project's key

[amiller]

proxy/dstack_proxy.py GetKey filter only requires the path to start with /tee-daemon/; it does not bind the path to the requesting project. A tenant with broker access could request:

GetKey {"path":"/tee-daemon/projects/<other>/..."}

and derive another project's key (cross-tenant key derivation).

Current check (insufficient)

KEY_PATH_PREFIX = "/tee-daemon/"
...
if method == "GetKey":
    path = body.get("path", "")
    if not path.startswith(KEY_PATH_PREFIX):
        ... deny

Proposed direction

Scope GetKey to the requesting project (only allow /tee-daemon/projects/<this-project>/...). This needs the broker to know the caller's project identity — e.g. a per-project broker socket, or caller attribution.

Cross-reference: #3, #4.

[amiller]

Decision (2026-07-07): per-project broker socket + name-based derivation

Chosen direction (operator-approved): Option 1 — identity by socket possession, not by inspecting a caller-supplied path.

Why not the alternatives

• Shared socket + path prefix check (today): the caller controls the path, so the check is only as good as string matching — the exact hole this issue reports. Rejected.
• Shared socket + caller attribution (SO_PEERCRED / source IP): recovers identity the Docker network already knows, but the peer-credential read is unreliable through gVisor's gofer (collides with Attested gVisor (runsc) tenants can't reach the broker unix socket — need host-UDS or a TCP broker #6 — attested runsc tenants), and a shared TCP broker reopens "who can route to it". Viable but fragile; not chosen.
• Shared socket + per-project bearer token: reintroduces a credential to inject/rotate/leak — the exact pattern this project exists to avoid. Rejected.

The design

1. The daemon binds one filtered proxy per project, each constructed with that project's project_id, listening on a per-project socket (/var/run/broker/<project>/dstack.sock).
2. Each project container is mounted only its own project socket at /run/broker/dstack.sock. Possession of that socket is the capability — a tenant cannot even address another project's keys.
3. Tenants send a key NAME, not a path. The proxy constructs "/tee-daemon/projects/" + project_id + "/" + name server-side. There is no prefix logic left to bypass.
4. Hardening regardless: canonicalize and reject .. so no /tee-daemon/projects/A/../B can sneak through if any path form survives.

Cost

Near-zero. DstackProxy already runs per-request in front of the real socket (proxy/main.py); this changes how many filtered sockets are bound and what each is pinned to, not the architecture. A unix socket is an fd + handler — no extra process, no network.

Coupling with #6

#6 (attested runsc tenants can't reach the broker UDS) should adopt the same shape: per-project UDS passed through the gofer (or per-project endpoint), NOT a shared TCP broker. Resolve #6 and #7 as one decision so #6 doesn't reintroduce the shared-endpoint identity gap.

Learn-the-pattern demo

A self-contained local docker-compose demo of this exact mechanism (watch the theft succeed in vulnerable mode, then get shut out in fixed mode) is being built as an operator briefing — link to follow.

Leaving needs-human (NOT ready) — this is core authz; the implementation issue will carry the acceptance criteria.

[amiller]

Runnable operator briefing for this decision is built: socket-tenant-demo/ (local docker-compose, stdlib Python, ~150 lines). ./run.sh runs both modes back to back — MODE=vulnerable reproduces this exact bug (one tenant derives another's key; the stolen key byte-for-byte matches the victim's own), MODE=fixed is the reference implementation for #80 (name-based, path built from the proxy's pinned project_id). README maps every piece back to proxy/dstack_proxy.py / proxy/main.py / proxy/deploy.py.