remote: trust only an installed tailscale, and prove every tailnet link

[krishhgg]

Four Greptile findings on Tailscale remote access.

An agent could choose the program that names the sender (#61, comment 4189642088)

The inbox gives the full session to a tailnet request that tailscale whois names as the owner. It ran whatever TOKENSTASH_TAILSCALE named, or the first tailscale on PATH, with the caller's environment. The inbox often inherits an agent's environment, so an agent could run a script that gave a local address to status and the owner's login to whois, then approve its own cards from a second local address.

• Release builds run only a tailscale from where Tailscale installs it. On Linux that is /usr/bin, /usr/sbin, /usr/local/bin or the NixOS system profile. On macOS it is the app bundle, /usr/local/bin or /opt/homebrew/bin. PATH is never searched, and the error names the places it looked.
• TOKENSTASH_TAILSCALE sits behind #[cfg(debug_assertions)], so the release binary does not contain the name. The integration test runs the debug binary and still uses it.
• tailscale runs with a fixed PATH and none of the caller's environment except HOME, because the CLI reads variables of its own and finds lsof on PATH on macOS. I checked that the real Linux CLI answers status and whois with an empty environment.
• SECURITY.md says what this covers and what it does not. It does not stop a process running as you from replacing the program where you can write to it (Homebrew's directories usually belong to you), or from reading the session file.

Test: remote::tests::the_tailscale_program_and_its_environment_are_not_the_callers.

Links could reuse an old ownership proof (#63, comment 4189607232; #71, comment 4189613086)

link_base kept a successful proof of the tailnet listener for 30 seconds. If the inbox stopped, or remote access went off and on, and another process took the address and port, a link with a card credential or the session could name it. The 30-second cache is gone. Each batch of links a command prints now rests on one fresh proof. A util::Links, made where the command already looks at the inbox on loopback, proves the address the first time a link needs it. Nothing outlives the command, and a command that waits makes a new one afterwards. A proof per link would have made a need with eight cards wait on nine proofs in a row (Greptile on this PR, comment 4189832693, fixed in 518d933).

While working on this I found that the inbox's own "Send the link to my desktop" button also built its link through link_base. That made the inbox probe its own tailnet listener from the one thread that answers the probe, so it waited out the 1.5 s timeout and then fell back to loopback. That link is now on loopback from the start. The notification shows on this computer, where 127.0.0.1 opens.

Tests: remote::tests::every_link_proves_the_tailnet_listener_again, cmd::inbox::tests::the_desktop_link_stays_on_loopback, and one_need_proves_the_tailnet_address_once in crates/cli/tests/remote_tailscale.rs. That last one puts a relay that counts connections on the Tailscale address. A need for three keys makes one proof there, where a proof per link made four.

A failed whois was kept for a minute (#63, comment 4189607267)

whois kept a failed lookup as "no login" for 60 seconds, so one Tailscale hiccup turned the owner's device away for a minute. Now only Tailscale's answers are kept, and a failure is asked again on the next request. The cache lock is no longer held while tailscale runs.

Test: remote::tests::a_failed_whois_is_asked_again_and_an_answer_is_kept.

whois held up the local inbox (#60, comment 4189643162)

The inbox ran whois, for up to 3 s, on the thread that answers every request. The reader thread that read a tailnet request now looks the sender up before it hands the request over, and handle reads the result. A device Tailscale cannot name still gets a 404, and this machine is still not looked up.

Test: a_slow_tailscale_lookup_does_not_hold_up_loopback in crates/cli/tests/remote_tailscale.rs. A device whose whois takes 2 s connects, and a loopback /verify must answer within 1 s. It fails with the lookup moved back to the main thread. The fake tailscale now takes its "slow status" flag from a file, since it no longer sees tokenstash's environment.

Checks

cargo clippy --workspace --all-targets --locked -- -D warnings, cargo test --workspace --locked, and scripts/leak-test.sh against both the debug and the release binary all pass.

🤖 Generated with Claude Code

Confidence Score: 5/5

The PR appears safe to merge; no new blocking issue was established.

What we checked:

• Slow lookup blocks the local inbox: No. A tailnet reader runs the lookup before handing the request to the thread that answers local requests.

Summary

The PR limits which tailscale program the CLI runs and moves tailnet lookups off the inbox’s main thread.

• It retries failed whois calls and replaces the 30-second link-proof cache with one proof per batch of links.
• It sends the inbox’s desktop link to loopback.
• krishhgg accepted the reader-availability risk because it requires a device on the user’s tailnet and slow lookups. krishhgg accepted the brief reused-link risk because a second proof would double the checks for that gap.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A[Tailnet request] --> B[Reader checks whois]
  B --> C[Inbox checks current setting and Host]
  C --> D{Login matches owner?}
  D -->|Yes| E[Serve as person]
  D -->|No| F[Return 404]
  G[Command builds links] --> H[Prove tailnet listener once]
  H --> I[Print link batch]

Loading

_{Reviews (3) · Last reviewed commit: "remote: prove the tailnet address once f..."}