anonym anonym@riseup.net writes:
It allows "GETINFO onions/current", which can expose a list of every onion service locally hosted, even those not launched through onionshare.
I think this can be disallowed; in fact, when looking at the onionshare and stem sources I don't see why this would ever be used by onionshare.
I may have said this already, but I think the original comment is wrong: this only lists ephemeral onions created by the current control connection so I don't believe there's any information leak here anyway.
BTW, I guess a `restrict-onion-view` would also make sense for HS_DESC events [..]
Yes, I think this would be good. To determine if a control-connection owns an onion or not, I think you could either use "GETINFO onions/current" (to ask Tor) or just remember the answers from any ADD_ONION on "this" connection (and then match against the args in the HS_DESC event).
If the filter is re-started, all the control connections will be lost at which point any non-"detached" onions will vanish anyway.
Imagine that ControlPort can take a "RestrictedView" flag. When set, controllers will get a view of Tor's state (streams, circuits, onions etc) restricted to what "belongs" to them, e.g. it only sees streams for connections itself made via the SocksPort. Tor would then have to internally track who these things belong to, which could be done by PID, which is pretty weak, but I bet there are more convincing ways.
Obviously as per my other post I agree with fragmented / limited views given to "real" applications of the control-port. However, personally I don't see the point of implementing this in 'tor' itself -- existing control-port filters are "fairly" limited code, typically in "safer than C" languages anyway. So then you have the situation where there's a single trusted application (the filter) conencted to the Tor control-port.
Ultimately, it would probably be best if there was "a" robust control-port filter that shipped as part of a Tor release. So if that means "must implement it in C inside Tor" I guess so be it.
Maybe this would be a good target for "experiment with Rust" if anyone's excited about writing control-port code in Rust...?