[tor-dev] Control-port filtering: can it have a reasonable threat model?

[meejah]

anonym <anonym at 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