Opened 3 years ago

Last modified 12 days ago

#14132 assigned enhancement

Add SocksSocket support to torsocks

Reported by: ioerror Owned by: sysrqb
Priority: Medium Milestone:
Component: Core Tor/Torsocks Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

In Paris, dgoulet and I started to write some basic torsocks support for SocksSocket (#12585) - in an ideal world, we'd have a Tor with a SocksSocket running by default. This would allow torsocks to do useful things by default - namely - any app can be instantly torified without worries about firewalls, users can be isolated from different socks proxies by uid, etc. Basically, I think it means that torsocks could default to SocksSocket, if built on a SocksSocket supporting platform.

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

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

dgoulet - do you still have the patch we started to write in paris?

Child Tickets

Change History (5)

comment:1 in reply to:  description Changed 3 years ago by dgoulet

Replying to 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!

comment:2 Changed 3 years ago by sysrqb

This is tricker than it should be. What's a good default path? By default, on Debian, /var/lib/tor and /run/tor are only readable by debian-tor. Many other distros and unixes have a similar configuration. Also, #15220 is mostly a blocker on this being used (unless the socket perms are manually adjusted).

comment:3 Changed 3 years ago by dgoulet

Keywords: isolation security socks removed
Owner: changed from dgoulet to sysrqb
Status: newassigned

I believe sysrqb is making good progress on this since the Tor meeting in Valencia so I'll assign this to him :).

comment:4 Changed 12 days ago by cypherpunks

Severity: Blocker

Any updates on sysrqb's progress? This is currently blocking #24037.

comment:5 Changed 12 days ago by cypherpunks

Severity: BlockerNormal

Wait what? I didn't try to change the severity to blocking. Does typing "is blocking <some ID>" automatically change the severity or something?

Note: See TracTickets for help on using tickets.