Use Tor Browser's integrated `AF_LOCAL` support on alpha.

The tbb_stub.so used by sandboxed-tor-browser currently overloads socket() and connect() to force Firefox into using an AF_LOCAL socket for the control and socks ports.

Once the stable release series has first class support for AF_LOCAL, the surrogate and stub should be changed to use those over the hack to reduce the amount of code in the stub.

Note: The stub has other duties and likely will be impossible to eliminate entirely, but the smaller the stub is the better.

added component::archived/tor browser sandbox owner::yawning priority::medium resolution::wontfix severity::normal status::closed type::enhancement labels

Trac:
Cc: N/A to brade, mcs

Trac:
Cc: brade, mcs to brade, mcs, gk

7.0 is stable in all forms now, so this should probably happen sooner rather than later, especially as it's trivial to do assuming the Tor Browser side works as advertised.

Trac:
Priority: Low to High

This looks as simple as:

Set the TOR_SOCKS_IPC_PATH env var to point to the SOCKS AF_LOCAL socket. Set the TOR_CONTROL_IPC_PATH env var to point to the control AF_LOCAL socket.

(It is somewhat annoying that the location of these two is split across torbutton/torlauncher, but at least I found them.)

Trac:
Status: new to assigned

Hm, I did those things in a branch, updated the control port surrogate's net/listeners/socks response, and cleaned up the stub, but I don't get a functioning browser.

As far as I can tell, torbutton claims that it will use the AF_LOCAL socket, but goes and opens an AF_INET socket instead for some inexplicable reason, resulting in a white window, where I expect content to be. Nothing helpful is logged either.

I might just punt on this, what's there is a bit messy, but it works, and there's no reason why it won't continue to work indefinitely.

Tor Browser apparently doesn't work as advertised, or there's more to it, and it's not actually high priority because the stub works as is.

Trac:
Priority: High to Medium

Unsandboxed Tor Browser 7.0.1:

socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 67
fcntl(67, F_GETFL)                      = 0x2 (flags O_RDWR)
fcntl(67, F_SETFL, O_RDWR|O_NONBLOCK)   = 0
socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = 68
close(68)                               = 0
socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = 68
fcntl(68, F_GETFL)                      = 0x2 (flags O_RDWR)
fcntl(68, F_SETFL, O_RDWR|O_NONBLOCK)   = 0
close(68)                               = 0
setsockopt(67, SOL_TCP, TCP_NODELAY, [1], 4) = 0

socket(AF_UNIX, SOCK_STREAM, 0)         = 68
fcntl(68, F_GETFL)                      = 0x2 (flags O_RDWR)
fcntl(68, F_SETFL, O_RDWR|O_NONBLOCK)   = 0
close(67)                               = 0
connect(68, {sa_family=AF_UNIX, sun_path="/var/run/tor/socks"}, 106) = 0

Without looking into the Firefox source, what I assume is happening in my branch is that the creation of the AF_INET/AF_INET6 sockets fail (with ENOSYS) due to the seccomp-bpf rules, and Firefox decides not to actually open the connection that will work.

When Tor Browser is configured to use AF_LOCAL, the two prior calls shouldn't happen to begin with.

Sandboxed Tor Browser 7.0.1 + Bug 20775 feature branch:

2017/07/02 13:58:47 firefox: tbb_stub: socket(2, 0x00000001, 0)
2017/07/02 13:58:47 firefox: tbb_stub: socket(2, 0x00000001, 0)

In the context of socket(), 2, is AF_INET. For debugging purposes, the stub is returning -1, with errno set to EAFNOSUPPORT, on the off chance that Firefox is freaking out about the ENOSYS response.

Opened #22794 (moved). This won't happen till that's fixed, because allowing non-AF_LOCAL socket creation in the seccomp-bpf policy is totally out of the question.

This project is deprecated, and none of these will ever be fixed.

Trac:
Resolution: N/A to wontfix
Status: assigned to closed

closed

mentioned in issue #20951 (moved)

mentioned in issue #22794 (moved)

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