anonym <ano...@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...? -- meejah _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
