[tor-bugs] #14132 [Torsocks]: Add SocksSocket support to torsocks
Tor Bug Tracker & Wiki
blackhole at torproject.org
Mon Jan 19 17:57:14 UTC 2015
#14132: Add SocksSocket support to torsocks
-----------------------------+----------------------------------------
Reporter: ioerror | Owner: dgoulet
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: Torsocks | Version:
Resolution: | Keywords: isolation, security, socks
Actual Points: | Parent ID:
Points: |
-----------------------------+----------------------------------------
Comment (by dgoulet):
Replying to [ticket:14132 ioerror]:
> Basically, I think it means that torsocks could default to SocksSocket,
if built on a SocksSocket supporting platform.
Agree here, if SocksSocket is enabled, we should definitely always use it.
It has a performance impact since we'll have to splice data from the unix
socket back to the inet socket given to the user but I don't think that
would be problematic in the long run. Not sure Torsocks should be used for
high performance app anyway :P
>
> I think for changes, we'd want to do the following:
>
> Add a configuration (in /etc/torsocks.conf ) option for the default
SocksSocket location
> eg: /var/lib/tor/SockSocket
Yes!
I would go with a new option in the configuration file that could be
{{{TorUnixSocket <path>}}} (or something like that) so if present,
torsocks will try it else will fallback on {{{TorAddress}}} being by
default localhost:9050.
> stat() the default SocksSocket file location
> if we find a SockSocket, we switch to AF_UNIX for all communications
> normal torsocks failures from here out
> if we don't find a SocksSocket
> fail hard? fail soft?
> if we fail soft, switch to the default _server_ configured
> if that fails, give an error and fail hard
Yes, I agree, if the option is explicitely in torsocks.conf, I would exit
here with an error message. If it's not in the configuration file, we use
a default Unix socket path and if fail, fallback to SocksPort. Makes
sense?
>
> dgoulet - do you still have the patch we started to write in paris?
(I've mentionned this to ioerror on IRC) - Nothing was done on torsocks
side unfortunately.
Now, this feature will be a bit tricky because, let's say ssh here,
expects an inet(4|6) socket to be sent back by socket() then passed to
connect(). So we can't send back a Unix socket instead and expect the
application to behave well with it. (Or maybe? we could try but I fear
we'll have unhappy apps or undefined behaviours...)
So, torsocks has to connect to tor through the Unix socket, send back an
inet(4|6) socket for which we tell the application "Yes it's connected"
but linked to the Unix socket connection and from there splice() data on
every I/O syscall between the inet socket to the tor Unix socket. That
will require torsocks so hijack every I/O operations like recvmsg, read,
write, etc...
It's will require some work, not too complicated though.
My approach here would go like this:
* Add configuration option to torsocks.
* Add a facility to find and test the Unix socket.
* Hijack all I/O ops (which btw is needed for optimistic data support! so
win-win)
* Connect the Unix socket and Inet socket together on a connection object.
* Happy dance!
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/14132#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list