[tor-bugs] #23277 [- Select a component]: ApplicationControlSocket: the way for apps to control Tor

Tor Bug Tracker & Wiki blackhole at torproject.org
Sat Aug 19 07:10:11 UTC 2017


#23277: ApplicationControlSocket: the way for apps to control Tor
--------------------------------------+------------------------------
     Reporter:  yurivict271           |      Owner:  (none)
         Type:  enhancement           |     Status:  new
     Priority:  Medium                |  Milestone:
    Component:  - Select a component  |    Version:  Tor: unspecified
     Severity:  Normal                |   Keywords:
Actual Points:                        |  Parent ID:
       Points:                        |   Reviewer:
      Sponsor:                        |
--------------------------------------+------------------------------
 ** Problem:

 When third party apps need to control Tor (most likely to create onions),
 they always face the choice of how to do this right. There are several
 options: 1. to start as root, connect to Tor, and setuid 2. to use the
 control port 9051, this will sometimes require password or cookie to
 authenticate 3. to run under group _tor and use control socket, reading
 auth-cookie or supplying password.

 These choices come up for all apps that need to control Tor, but which are
 otherwise unrelated to Tor. Lack of clear recipe as of what should they
 choose to do and the complexity involved in this decision give rise to
 random behaviors, unsafe practices, etc.

 ** Proposed solution:

 New torrc instruction ApplicationControlSocket:
 > ApplicationControlSocket group_name /path/to/app/socket
 (cookie:/path/to/app/cookie_auth_file|hash:16:XXXXX...)

 Arguments:
 * group_name: UNIX group name this instruction applies to
 * /path/to/app/socket: path where Tor will create the UNIX socket
 * (cookie:/path/to/app/cookie_auth_file|hash:16:XXXXX...): either the path
 to auth-cookie file, or hashed password.

 Every application that needs to control Tor runs as its own group. This
 group has this instruction in torrc that enables it to control Tor.

 Tor will create a special control socket just for this group. Optionally,
 Tor will create the auth-cookie file. Tor will check credentials of
 incoming connections, and will reject any connection not coming from the
 process with this specific group, or when the user is not a member of this
 group. Tor will make permissions on socket and auth-cookie files like
 this: ----rw---- _tor:{group_name}.

 ** Pros/Cons:

 Pros:
   * Easy to use and understand
   * Apps will have no need to make choices and reinvent the wheel
   * This will be a standard, suggested way
   * Reduces the chance to have unsafe setups
   * Eliminates the need to have the potentially unsafe control port 9051

 Cons:
   * Some effort to implement

 ** Limitations:

 Only applicable to OSes where UNIX sockets are available: Linux, BSD,
 MacOS, SunOS. Probably not on Windows.

 ** Examples of apps:
 * ZeroNet (can run with its own group zeronet)
 * Tox (can require user to be a member of tox group allowed to control
 Tor)
 * RetroShare (can require user to be a member of group retroshare)

 Alternatively, UI apps can share the group, ex. require the user to be a
 member of 'tor-controllers', and share one ApplicationControlSocket
 instruction.

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


More information about the tor-bugs mailing list