Hi everyone!
This is the release for version 2.1.0 of Torsocks. Special thanks to Yawning that helped a lot with the new features, finding bugs and providing patches! Also, thanks to all contributors and users out there providing us with feedbacks! :)
Changes that are worth mentionning:
- Support for TCP fast open.
- AllowOutboundLocalhost option allows torsocks to connect to a localhost address.
- IsolatePID is a new option that will make torsocks set the SOCKS5 username and password automatically to provide isolation on Tor side.
You can use this with the -i,--isolate command added or TORSOCKS_ISOLATE_PID env. variable.
- Fix initialization phase when used with C++.
- Way less annoying warnings of syscall being denied. Most of them were harmless so we let them pass now.
- Multiple fixes! (see changelog below)
Here is the change log for this version.
2015-05-27 torsocks 2.1.0 * Fix: socks5 resolve wasn't sending data correctly * Fix: wrong label when auth_socks5 fail * Move SOCKS5 auth in a seperate function * Send the SOCKS5 authentication for RESOLVE/RESOLVE_PTR requests. * Change IsolatePID password from 42 to 0 * Add automatic per process isolation (IsolatePID) * Ensure that torsocks initializes itself in the presence of C++. * Merge remote-tracking branch 'yawning/getaddrinfo' into getaddrinfo * Fix: indentation in getpeername test * Merge remote-tracking branch 'yawning/getpeername' * Add support for the various inotify routines when invoked via syscall(). * Support the eventfd2(2) syscall. * Support the various epoll routines when invoked via syscall(). * Handle accept4(2) when invoked via syscall(). * Fix getaddrinfo() to respect AI_NUMERICHOST. * Fix the broken getpeername() implementation. * Support certain Linux specific syscalls. * Allow TCP Fast Open clients go through tor * Test: support out of tree make check * configure.ac: avoid tests which have both -pie and -static * Fix error messages about setuid/setgid executables * Fix: switch back to a syscall whitelist scheme * Add AllowOutboundLocalhost. * Fix: syscall mmap for NetBSD * Fix: use getsockname instead of getsockopt to get socket family * Stop denying syscall() and add dangerous ones * Fix: typo in the listen macro declaration * Fix: improve getpeername to actually works * Fix: improve Unix socket passing detection * Test: add missing connection destroy * Test: possible double free in onion test * Test: fix memory leak in DNS test * Add accept as an accepted value through syscall() * Add cscope files to gitignore
Again, as usual, and forever! *please* code review, test and most importantly report any issues. Contribution ftw! :)
Thanks to everyone!
Git: https://gitweb.torproject.org/torsocks.git
Tarball: https://people.torproject.org/~dgoulet/torsocks/torsocks-2.1.0.tar.bz2 (sig: https://people.torproject.org/~dgoulet/torsocks/torsocks-2.1.0.tar.bz2.asc)
Cheers! David
On 05/27/2015 09:19 PM, David Goulet wrote:
IsolatePID is a new option that will make torsocks set the SOCKS5 username and password automatically to provide isolation on Tor side.
You can use this with the -i,--isolate command added or TORSOCKS_ISOLATE_PID env. variable.
Perhaps I'm overlooking the purpose of this option, but it doesn't look like something you can rely on to get stream isolation between separate torsocks invocations. For instance, on a POSIX-compliant system a PID can be reused as soon as the process using it has terminated. This implies that, for any purpose, a PID should only be used as a unique identifier for the duration of the process using it.
Assuming the purpose is to provide stream isolation between torsocks invocations, why not generate a big random numbers for the socks auth user/password instead? 256 bits should be enough even when taking the birthday paradox into account.
In practice PID resuage perhaps isn't a problem for any realistic use case, making my remarks into theoretical nitpicking, but YMMV.
Cheers!
On Thu, 28 May 2015 14:55:07 +0200 anonym anonym@riseup.net wrote:
On 05/27/2015 09:19 PM, David Goulet wrote:
- IsolatePID is a new option that will make torsocks set the SOCKS5 username and password automatically to provide isolation on Tor
side.
You can use this with the -i,--isolate command added or TORSOCKS_ISOLATE_PID env. variable.
Perhaps I'm overlooking the purpose of this option, but it doesn't look like something you can rely on to get stream isolation between separate torsocks invocations. For instance, on a POSIX-compliant system a PID can be reused as soon as the process using it has terminated. This implies that, for any purpose, a PID should only be used as a unique identifier for the duration of the process using it.
Assuming the purpose is to provide stream isolation between torsocks invocations, why not generate a big random numbers for the socks auth user/password instead? 256 bits should be enough even when taking the birthday paradox into account.
In practice PID resuage perhaps isn't a problem for any realistic use case, making my remarks into theoretical nitpicking, but YMMV.
Ah, this is a matter of "the feature is explained in a simple manner in the abbreviated changelog".
What the flag actually does is: * Username set to 'torsocks-' PID ':' unixTime * Password set to '0'. (If one day torsocks wants to add something like a signal handler to get tor browser 'new circuit' type behavior, my plan was to increment this, not currently used).
While not as great as 256 bit random numbers, PID reuse within the same second is rather unlikely, at least under Linux PIDs are only recycled when the pid wraps (/proc/sys/kernel/pid_max), I assume most other Unixes follow similar behavior.
The identifier was chosen such that it would be blatantly obvious in circuit listings as to which torsocks instance things belong to. There is space in the username field, so appending a hexdecimal large random number or something is certainly possible and quite trivial.
Regards,
On 05/28/2015 03:11 PM, Yawning Angel wrote:
Ah, this is a matter of "the feature is explained in a simple manner in the abbreviated changelog".
What the flag actually does is:
- Username set to 'torsocks-' PID ':' unixTime
Thanks for the clarification! This indeed sounds a lot better.
While not as great as 256 bit random numbers, PID reuse within the same second is rather unlikely, at least under Linux PIDs are only recycled when the pid wraps (/proc/sys/kernel/pid_max), I assume most other Unixes follow similar behavior.
Right. I wrote something about this originally, but ended up deleting it for brevity. I think we would have to come up with some pretty ridiculous scenarios for it to become a problem on Linux even without the unix timestamp (only PIDs), e.g. massively parallel runs of torsocks + other processes cycling through PIDs rapidly + an increased MaxCircuitDirtiness + lowered pid_mix, or some combination thereof.
But still, YMMV depending on your OS. :)
The identifier was chosen such that it would be blatantly obvious in circuit listings as to which torsocks instance things belong to.
Makes sense.
There is space in the username field, so appending a hexdecimal large random number or something is certainly possible and quite trivial.
It would be a welcome improvement if you have the time. And if space is an issue the unix time can of course be dropped.
Cheers!
On Thu, May 28, 2015 at 9:11 AM, Yawning Angel yawning@schwanenlied.me wrote:
While not as great as 256 bit random numbers, PID reuse within the same
There's often a case for combining human meaning with random. On the random... Width of pid+epoch is 48 bits. CPU 4GHz per epoch = 32 bits. 48+32=80. ssh-agent deems (a-zA-Z0-9)^12 = 71+ bits in /tmp. 14 of those chars = 83+ bits, more than current onion. So doubt you really need to stuff 43 = 256+ bits onto a human readable field.
-
anonym -
David Goulet -
grarpamp -
Yawning Angel