Hacker News Reader

[co-author of the research here]

They actually approximate this functionality in the Windows implementation: It checks netstat to enforce that incoming TCP connections are from the expected Windows user! https://github.com/tailscale/tailscale/blob/2a991a3541ae5d56...

That's why we were happy with the solution they implemented as a stopgap, until they could switch to named pipes (which there is now an open PR for).

View on HN

Huh, ok, that's not so bad then.

It feels like there could still be a TOCTOU issue there, but it'd be difficult to use.

Generally speaking, allowing privileged operations because a specific user asked over a TCP socket is asking for trouble: there are quite a few ways that unwitting processes could open a socket on behalf of an attacker without realizing that it is asserting its identity and thus granting privilege.

All the major cloud get this IMO entirely wrong with their services that issue secrets to instances (e.g. AWS IDMS).

With tcp being connection-oriented I think it's not too hard to get right, especially if the OS won't reuse a closed socket right away. Definitely worth considering though. Of course it's doable without netstat if you can track down the right apis https://stackoverflow.com/questions/47659365/find-process-ow...

Reply on news.ycombinator.com