Hi Nick. Just a quick note that something I've wanted from time to time is a 'make the control port read-only' option so only GETINFO, GETCONF, events, etc would work. Yes, these could be used to deanonymize a user, but it could provide assurance the controller doesn't tamper with tor. This has been of interest to me since nyx (aka arm) is primarily a read-only monitor and this could provide users with an assurance that it's not doing anything to their tor instance.
Besides that, 'makes the control port read-only' is a pretty straight forward, simple to understand capability for a torrc option to have. Cheers! -Damian On Mon, Apr 3, 2017 at 11:41 AM, Nick Mathewson <ni...@torproject.org> wrote: > Hi! > > As you may know, the Tor control port assumes that if you can > authenticate to it, you are completely trusted with respect to the Tor > instance you have authenticated to. But there are a few programs and > tools that filter access to the Tor control port, in an attempt to > provide more restricted access. > > When I've been asked to think about including such a feature in Tor in > the past, I've pointed out that while filtering commands is fairly > easy, defining a safe subset of the Tor control protocol is not. The > problem is that many subsets of the control port protocol are > sufficient for a hostile application to deanonymize users in > surprising ways. > > But I could be wrong! Maybe there are subsets that are safer than others. > > Let me try to illustrate. I'll be looking at a few filter sets for example. > ===== > Filters from https://github.com/subgraph/roflcoptor/filters : > > 1. gnome-shell.json > > This filter allows "SIGNAL NEWNYM", which can potentially be used to > deanonymize a user who is on a single site for a long time by causing > that user to rebuild new circuits with a given timing pattern. > > 2. onioncircuits.json > > Allows "GETINFO circuit-status" and "GETINFO stream-status", which > expose to the application a complete list of where the user is > visiting and how they are getting there. > > 3. onionshare-gui.json > > Allows "SETEVENTS HS_DESC", which is exposes to the application every > hidden service which the user is visiting. > > 4. ricochet.json > > Allows "SETEVENTS HS_DESC", for which see "onionshare-gui" above. > > 5. tbb.json > > Allows "SETEVENTS STREAM" and "GETINFO circuit-status", for which see > "onioncircuits" above. > > ===== > Filters from > https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/etc/tor-controlport-filter.d > : > > 1. onioncircuits.yml > > See onioncircuits.json above; it allows the same GETINFO stuff. > > 2. onionshare.yml > > 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. > > 3. tor-browser.yml > > As "tbb.json" above. > > 4. tor-launcher.yml > > Allows setconf of bridges, which allows the app to pick a hostile > bridge on purpose. Similar issues with Socks*Proxy. The app can also > use ReachableAddresses to restrict guards on the . > > Allows SAVECONF, which lets the application make the above changes > permanent (for as long as the torrc file is persisted) > ===== > > So above, I see a few common patterns: > * Many restrictive filters still let the application learn enough > about the user's behavior to deanonymize them. If the threat model is > intended to resist a hostile application, then that application can't > be allowed to communicate with the outside world, even over Tor. > > * Many restrictive filters block SETCONF and SAVECONF. These two > changes together should be enough to make sure that a hostile > application can only deanonymize _current_ traffic, not future Tor > traffic. Is that the threat model? It's coherent, at least. > > * 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? > > * The NEWNYM-based side-channel above is a little scary. > > > And where do we go forward from here? > > The filters above seem to have been created by granting the > applications only the commands that they actually need, and by > filtering all the other commands. But if we'd like filters that > actually provide some security against hostile applications using the > control port, we'll need to take a different tactic: we'll need to > define the threat models that we're trying to work within, and see > what we can safely expose under those models. > > Here are a few _possible_ models we could think about, but I'd like to > hear from app developers and filter authors and distributors more > about what they think: > > A. Completely trusted controller. (What we have now) > > B. Controller is untrusted, but is blocked from exfiltrating information. > B.1. Controller can't connect to the network at all. > B.2. Controller can't connect to the network except over tor. > > C. Controller is trusted wrt all current private information, but > future private information must remain secure. > > D. Controller is trusted wrt a fraction of the requests that the > clients are handling. (For example, all requests going over a single > SOCKSPort, or all ADD_ONION requests that it makes itself.) > > E. Your thoughts here....? > > > > > signing-off-before-this-turns-into-a-capabilities-based-system, > -- > Nick > _______________________________________________ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev