Loopback bind bounds remote reach, not local — and the device gate fails open on an absent header

[simonallfrey]

Not a privilege-escalation report. §6 already says the herdr socket equals arbitrary code execution, and herdr advertises agent socket access as a feature. The narrower point: herdr's socket and Collie's port have different reachable sets, and §6 doesn't distinguish them.

herdr's socket is a filesystem object — permissions bound callers to the owning uid. Collie binds 127.0.0.1:8787, reachable by every uid in the netns. §6 calls the loopback bind load-bearing; it is, against remote callers. Locally it bounds nothing, and the doc reads as though it does.

Concrete case. I run review agents on untrusted diffs under a separate uid — sudo -u agent-review claude inside the pane. That uid can't open my herdr socket, so a prompt injection in a diff can't reach my other panes. It can open 127.0.0.1:8787, so with Collie running it can:

curl -X POST http://127.0.0.1:8787/api/pane/<id>/keys \
  -H 'content-type: application/json' -d '{"keys":["..."]}'

— and type into any pane in the herd. checkAccess passes (Host is loopback, so the no-Origin write path is allowed; COLLIE_PUBLIC_HOSTS is empty by default so the host allowlist never runs). deviceAuth returns authorized: true on the absent header. Installing Collie silently removes the uid boundary, which is the containment an operator running agents is most likely to have reached for.

The fix already exists in the code. deviceAuth() fails open:

if (!device) return { enforced: true, device: null, authorized: true };

Rationale given: an absent header is the on-host loopback operator. That's the same "local means trusted" assumption.

Deny writes on an absent header when COLLIE_DEVICE_HEADER is set, and treat allowlist entries as secrets rather than device names, and this becomes a bearer token — reaching the port stops being sufficient to write. Few lines, no new machinery, no Tailscale dependency, so it covers Variant C too.

Same change closes a doc/code gap: §6 says the owner login is asserted and other tailnet users rejected, but checkAccess only rejects a mismatching Tailscale-User-Login and passes an absent one. Fine under tailscale serve, which always injects it; not fine behind a proxy that stops.

If unix-socket listen was on the roadmap: Tailscale restricted Serve's unix-socket proxy targets to root in TS-2026-005, and collie-ctl.sh runs serve as the operator. That route costs root now.

If the fail-closed change isn't wanted, a sentence in §6 covers most of it: the loopback bind bounds remote reach only, and agents under a separate uid are not isolated from the bridge. Happy to PR the deviceAuth change.

[simonallfrey]

Oh and great work, I was just about to get down to building the safe thing. Tx

[AltanS]

Both halves are handled — thanks, this was a good report.

The deviceAuth fail-closed change shipped in 0.15.0 (#28, from @Optic00, filed in parallel with this). With COLLIE_DEVICE_HEADER set, an absent header is now read-only, so reaching the port stops being sufficient to write. Flagged breaking, since anyone with the header configured and no injector in front loses write access on upgrade.

Worth adding that on my own deployment this closed a live bypass rather than a theoretical one, in a shape adjacent to yours: the reverse proxy that injects the header runs on a different node, and its upstream is the bridge's own tailnet URL — so that URL was a permanent second path with no header and full write. Same root assumption, reached from the network side instead of the uid side.

The doc half is #35. You were right that §6 read as though the loopback bind bounded local callers; it now says it bounds remote reach only, and that an agent under another uid can still drive the herd through the port. Your checkAccess catch is in there too — §6 claimed the owner login was asserted and other tailnet users rejected, when it only rejects a mismatching login and passes an absent one.

Not taking the bearer-token suggestion for now. Device ids stay proxy-asserted names, with the front door and its ACL as the containment — a secret in a header the proxy injects is the proxy's to manage, and folding one into COLLIE_DEVICE_ALLOWLIST would make an .env value that looks like a device name into a credential. Open to it as its own issue if you think that's the wrong call.

The TS-2026-005 note on unix-socket serve targets was useful — that route is off the table.

[simonallfrey]

Great turnaround :-) You think over cautious some kind of clarification like:

Important local-read boundary: Collie’s loopback HTTP port is reachable by
other local users on the same host. COLLIE_DEVICE_HEADER only gates writes;
read endpoints remain available to any local uid that can connect to
127.0.0.1:$COLLIE_PORT. That includes snapshots, pane output, and transcript
history. If local uid separation is part of your threat model, do not run
Collie on a shared loopback port without an additional read gate, uid-isolated
network namespace, or firewall policy.

[AltanS]

Not over-cautious. Good catch, and thanks for coming back on it.

You're right: the gate is writes-only, so pointing a uid-containment reader at it only fixes half their problem, and the open half is the one that leaks. A local curl still gets /api/snapshot, pane output and /history.

Fixed the two spots that oversold it. README sharp edge now says writes only, reads stay open. ARCHITECTURE §6 said "close the port"; it doesn't, it makes it read-only.

Two tweaks to your wording, both in §6: a plain firewall rule won't stop a same-host peer, so closing reads means an unshared port (own netns, or a uid match like nftables meta skuid). And it isn't only local uids; any header-less caller reads.