[tor-bugs] #3076 [Tor Client]: Implement 'SocksPort auto' and 'ControlPort auto'

[Tor Bug Tracker & Wiki]

#3076: Implement 'SocksPort auto' and 'ControlPort auto'
-------------------------+--------------------------------------------------
 Reporter:  mikeperry    |          Owner:                    
     Type:  enhancement  |         Status:  needs_review      
 Priority:  major        |      Milestone:  Tor: 0.2.2.x-final
Component:  Tor Client   |        Version:                    
 Keywords:               |         Parent:  #2264             
   Points:               |   Actualpoints:                    
-------------------------+--------------------------------------------------

Comment(by mikeperry):

 Replying to [comment:10 nickm]:
 > Wrote a patch to implement ControlPortWriteToFile; see the updated
 feature3076 branch in my public.

 It looks like you're going to create a temp file here if it already
 exists, and then replace the existing file due to magic in
 start_writing_to_file()? This may have consequences for my permissions
 comments below..

 Also, perhaps the man page should specify that the file name can be
 relative to the current working directory of the tor process? Or do we
 want to default to the Tor data directory, or config directory?

 > But on consideration I am worried about MITM issues here: the patch
 would make it easier to wind up in a situation where an attacker can
 listen on port X and convince the controller to connect to port X instead
 of to Tor... either by reading a stale file and binding to the listed
 port, or by overwriting the file with a new port.  Should we care?  Can we
 do anything about this?

 I think we can assume that anyone with write access to the torrc wins, so
 we only need to consider new vulnerabilities for installs that will use
 this feature by default. There are then two major use cases to consider:
 distribution packages, and our bundles.

 Since distributions may perform their own custom least-privilege
 implementations, I think if we explicitly set this file to 640 in the
 code, that this should clue those people in to the fact that we only want
 tor and vidalia to be able to read this file, if they even decide to
 enable this option. I don't envision system tor installs needing or
 wanting this option, though.

 If we think about our own packages, I think we also only really want this
 feature for the non-expert Tor Browser Bundles. I think we lose the least-
 privilege possibility right off the bat for them. For those bundles, the
 same account will run vidalia, tor and Firefox. If this is the same
 account that has filesystem ownership of the bundle files, that account
 can exploit the bundle in a lot of ways (such as altering torrc or the
 binaries).

 If the filesystem owner account is not used to launch the bundles, we may
 be opening up new vulnerabilities by allowing this secondary account to
 access this file. But it's also not clear how well the bundles will
 function without write access to their data directory and CWD (where
 everything lives)... The state file can't be written to save guards or CBT
 data, for example, so this appears to be a non-recommended situation
 rather than a more secure one.

 Am I right here? It looks to me for the cases where this will be used, it
 doesn't give any additional ability, so long as we make sure it is
 readable only by the bundle user and not o+r.

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