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

[meejah <meejah@xxxxxxxxx>]

Nick Mathewson <nickm@xxxxxxxxxxxxxx> writes:

> But I could be wrong!  Maybe there are subsets that are safer than
> others.

So, I guess the "main" use-case for this stuff would be the current
users of control-port filters (like Subgraph and Whonix; others?).

It seems what these things *really* want is a "limited view" of the One
True Tor. So for example, you don't want to filter on the "command" or
"event" level, but a complete coherent "version" of the Tor state.

As in: see "your" STREAM events, or "your" HS_DESC events etc. Probably
the same for BW or similar events. This is really kind of the
"capability system" you don't want, though ;)

Also, I really don't know exactly what the threat-model is, but it does
seem like a good idea to limit what information a random application has
access to. Ideally, it would know precisely the things it *needs* to
know to do its job (or at least has been given explicit permission by a
user to know). That is a user might click "yes, OnionShare may add onion
services to my Tor" but in reality you have to enable: ADD_ONION, (some)
HS_DESC events, DEL_ONION (but only ones you added), etc. If you really
wanted an "on-disk" one (i.e. via HiddenServiceDir not ADD_ONION), then
you have to allow (at least some) access to SETCONF etc.

Or, maybe you're happy to let that cool visualizer-thing have access to
"read only" events like STREAM, CIRC, BW, etc if you know it's sandboxed
to have zero network access.

> As above, appears to allow HS_DESC events.  It allows "GETINFO
> onions/current", which can expose a list of every onion service
> locally hosted, even those not launched through onionshare.

Doesn't this just show "onions that the current control connection has
added"?

>   * Some applications that care about their own onion services
> inadvertantly find themselves informed about everyone else's onion
> services.  I wonder if there's a way around that?

HS_DESC events include the onion (in args) so could in principle be
filtered by a control-filter to only include events for certain onions
(i.e. those added by "this" control connection). In practice, this is
probably exactly what the application wants anyway.

>  E.  Your thoughts here....?

Maybe this is a chance to play with a completely different, but ideally
much better "control protocol for Tor"? The general idea would be that
you have some "trusted" software (i.e. like existing control-port
filters) that on the one side connects to the existing control-port of
Tor (and is thus "completely trusted") but then exposes "the Next Great
Control Protocol" to clients.

Nevertheless, there's still the question of what information to expose
(and how) -- i.e. the threat model, and use-cases.

Of course, the same idea as above could be used except it speaks "Tor
Control Protocol" out both sides -- that is, 'just' a slightly fancier
filter.

> signing-off-before-this-turns-into-a-capabilities-based-system,

Aww, that's what I want ;)

-- 
meejah
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev