[tor-bugs] #8369 [Tor]: Option to limit information Tor's control port discloses

[Tor Bug Tracker & Wiki]

#8369: Option to limit information Tor's control port discloses
-----------------------------+--------------------------
     Reporter:  proper       |      Owner:
         Type:  enhancement  |     Status:  new
     Priority:  normal       |  Milestone:  Tor: 0.2.???
    Component:  Tor          |    Version:
   Resolution:               |   Keywords:  tor-client
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+--------------------------

Comment (by arma):

 We talked more about this ticket on #tor today.

 An adversary who can talk to the control port can learn who the user is,
 via not just getinfo address, but also setconf'ing a proxy or alternate
 directory authorities or bridges or the like, or by listening to events
 (including log events) that say details. And if setconf is dangerous,
 don't skip over loadconf. In short, I don't think a "blacklist these
 dangerous controller commands" approach will work -- there are too many of
 them.

 We could imagine whitelisting a small set, like the ones that Whonix and
 Tails both use.

 But that whitelist won't be something that Tor Browser would want to
 apply, since Tor Launcher *does* want to be able to setconf proxies or
 bridges, and listen for events.

 Developers who use the control port would of course like a fully
 expressive language to describe exactly which features in the control
 protocol should be handled in what ways. But I think it would be unwise to
 build such a thing into Tor, because it would be a lot of code, which
 would be a lot of room for bugs, and approximately none of the code would
 be used by most users, so many bugs would lurk for a long time.

 And since the various users here will want to be able to configure which
 commands are allowed or disallowed (I hear some Whonix users will want to
 be able to configure hidden services, whereas others will want their Tor
 to prevent them from configuring hidden services), it seems to me that the
 current "run a script that is the gatekeeper for what commands can
 actually get passed through to the Control interface, and then users can
 configure the script as needed to allow whatever features they're
 enabling" approach is not horrible.

 The push-back against that approach is that the current script is written
 in bash, and maybe there are sneaky ways to trick it into passing along
 commands you wanted to block. Which, while true, doesn't really convince
 me that putting that stuff, in a sufficiently configurable way, inside Tor
 will make things any better.

 At the same time, I still don't have a good handle on the threat model
 that we're considering here. The Tor process knows sensitive information,
 after all, so you need to somehow prevent the adversary, who in this
 scenario has broken into some of the computer but not all of it, from
 interacting with the Tor process, but you do want to allow the user to
 change things, including what interactions are allowed with the Tor
 process? I guess if the browser is run in one VM, and the Tor configurer
 interface is run in a different VM, we could have a hope of making this
 work -- but once you've got the usability issues sorted out there, tell me
 again why the browser VM needs to be the one to click 'new identity'? I
 guess the broader answer is that I'm not yet convinced that this ticket,
 "option to limit information Tor's control port discloses", is addressing
 the right underlying issue.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/8369#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online