Opened 13 months ago

Last modified 6 months ago

#20775 assigned enhancement

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

Reported by: yawning Owned by: yawning
Priority: Medium Milestone:
Component: Applications/Tor Browser Sandbox Version:
Severity: Normal Keywords:
Cc: brade, mcs, gk Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

TicketTypeStatusOwnerSummary
#22794defectnewtbb-teamDon't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.

Change History (9)

comment:1 Changed 13 months ago by mcs

Cc: brade mcs added

comment:2 Changed 13 months ago by gk

Cc: gk added

comment:3 Changed 6 months ago by yawning

Priority: LowHigh

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.

comment:4 Changed 6 months ago by yawning

Status: newassigned

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.)

comment:5 Changed 6 months ago by yawning

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.

comment:6 Changed 6 months ago by yawning

Priority: HighMedium

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.

comment:7 Changed 6 months ago by yawning

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.

comment:8 Changed 6 months ago by yawning

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.

comment:9 Changed 6 months ago by yawning

Opened #22794. 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.

Note: See TracTickets for help on using tickets.