On 04 Mar (08:36:13), Nick Mathewson wrote:
On Mar 4, 2014 4:26 AM, "Lunar" lunar@torproject.org wrote:
David Goulet:
After a big code review from Nick and help from a lot of people contributing and testing, this is the release candidate 4 for the new torsocks.
I was about to push the new version to Debian experimental, but it just breaks my SSH configuration too badly.
The new version forbids listen() and accept().
That means that at least SSH options ControlMaster, LocalForward, and DynamicForward will not work. Being able to multiplex connections (ControlMaster) is pretty crucial to keep sanity when working over hidden services. Forwarding options allow a simple way to create to tunnel TCP connections to a remote system through SSH over Tor.
I am not sure what is the right move here. Perhaps allowing listen on Unix sockets and localhost? Or maybe allowing listen() entirely?
Those sound like good candidates for options. I think that listen-local is probably safe*, but arbitrary listen is broken in enough use cases that it should IMO be off by default.
I agree here that this should not break the ssh -L. What I propose is an option that allows torsocks to accept inbound connection thus listen()/accept().
An option in the configuration file and an environment variable also (which adds a command line option to torsocks as well). What about "AllowInbound" or "AllowListen" or "AcceptListen" that is off by default.
Thoughts?
*do we need to do anything about fds transferred over Unix sockets? Probably.
Right now, torsocks detects that and stops everything! Since we have no way of handling that already connected socket inside the torified application, the behavior is to abort, abort and abort...
Cheers! David
Yrs,
Nick
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev