Make Tor Launcher work with Unix Domain Socket option

In order to enhance the security of the Tor Browser we should at least for *NIX systems support the recently landed Unix Domain Socket option.

added TorBrowserTeam201608R component::applications/tor launcher owner::brade parent::14270 priority::high resolution::fixed severity::normal sponsor::U status::closed tbb-security type::enhancement labels

Trac:
Cc: N/A to brade, mcs

Trac:
Summary: Make Tor Launcher work with SocksSocket option to Make Tor Launcher work with Unix Domain Socket option
Description: In order to enhance the security of the Tor Browser we should at least for *NIX systems support the recently landed SocksSocket option.

to

In order to enhance the security of the Tor Browser we should at least for *NIX systems support the recently landed Unix Domain Socket option.

We're wondering on how one would still be able to use Tor Browser behind a Transparent/Isolating Proxy, Whonix, without Tor over Tor then.

While you're at this, could you please add support for connecting to an already, previously existing unix domain socket file? Such as an environment variable export TOR_PRE_EXIST_UNIX_SOCKET=/path/to/socket (or so)? (The creation of that socket would be up to the user of such an TOR_PRE_EXIST_UNIX_SOCKET environment variable.)

(We could then use socat to create the socket and to forward it to another IP/port where Tor is listening.)

Trac:
Cc: brade, mcs to brade, mcs, adrelanos@riseup.net

Trac:
Status: new to assigned
Owner: gk to brade

Trac:
Cc: brade, mcs, adrelanos@riseup.net to brade, mcs, adrelanos@riseup.net, whonix-devel@whonix.org

Replying to brade:

Replying to proper:

As far I understand, this is up to Make Tor Launcher work with Unix Domain Socket option (#14272 (moved)). What is Tor Button's role in this?

Torbutton includes code that interacts with tor via the control port (e.g., newnym, circuit display). If we disable all TCP in Tor Browser, control port communication will need to be via a Unix domain socket as well (so Torbutton will need to be modified).

Then I must write an update to my previous post. :)

We're wondering on how one would still be able to use Tor Browser behind a Transparent/Isolating Proxy, Whonix, without Tor over Tor then.

While you're at this, could you please add support for connecting to an already, previously existing unix domain socket files? Such as an environment variables:

• export TOR_PRE_EXIST_UNIX_SOCKET_SOCKS=/path/to/socket
• export TOR_PRE_EXIST_UNIX_SOCKET_CONTROL=/path/to/socket (or so)

(The creation of these unix domain socket files would be up to the user of these environment variables.)

(We could then use socat to create the socket and to forward it to another IP/port where Tor is listening.)

Trac:
Sponsor: N/A to SponsorU
Priority: Medium to High

Getting important SponsorU things on our August radar.

Trac:
Keywords: N/A deleted, TorBrowserTeam201608 added

Switching to a Unix domain socket for the control port turns out to mostly be a matter of configuration plus creation of a different kind of socket transport. Here is a patch for review: https://gitweb.torproject.org/user/brade/tor-launcher.git/commit/?h=bug14272-01&id=fe86a337bac123466433a5d7dff19333b5907daf

Trac:
Severity: N/A to Normal
Status: assigned to needs_review
Keywords: TorBrowserTeam201608 deleted, TorBrowserTeam201608R added
Reviewer: N/A to N/A

Two things (no need to create a new branch if 2. is moot):

1. In the commit description s/is is use/is in use/

2. Why do we have a new param for getTorFile()? Do we expect more calls with aMustExist === false? If not, why not just omit that param (and do something like "control_socket" == aTorFileType again) or at least rename it to something more descriptive than aMustExist (like aControlSocket)?

I was confused about the !aMustExist check as the connection between that and doing f.normalize(); seems not obvious at first glance.

Replying to gk:

Two things (no need to create a new branch if 2. is moot):

1. In the commit description s/is is use/is in use/

Oops. Thanks!

2. Why do we have a new param for getTorFile()? Do we expect more calls with aMustExist === false? If not, why not just omit that param (and do something like "control_socket" == aTorFileType again) or at least rename it to something more descriptive than aMustExist (like aControlSocket)?

Kathy and I like your suggestion. Here is a revised patch: https://gitweb.torproject.org/user/brade/tor-launcher.git/commit/?h=bug14272-02&id=8871259c966755233b134a5ddb2b4926539d25c6

Thanks, this is commit 8871259c966755233b134a5ddb2b4926539d25c6 on master. I'll get that onto the proper maint branch for the alphas later. I added a typo-fix-commit as well (commit 32ddac7015be571c336be686b4f901103d0d36f6) to save us one round-trip.

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

closed

mentioned in issue #20075 (moved)

mentioned in issue #20111 (moved)

mentioned in issue #20761 (moved)

moved to tpo/applications/tor-launcher#14272 (closed)

mentioned in issue tpo/applications/tor-launcher#20075 (closed)

mentioned in issue tpo/applications/tor-browser#20111 (closed)