GitLab

Discovered when trying to resolve legacy/trac#20775 (closed).

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

If the first socket (AF_INET) call fails (as it will due to seccomp-bpf) the AF_LOCAL socket never gets created, and pages don't load. The failure mode doesn't appear to depend on errno (at least, it didn't make a difference if it was ENOSYS or EAFNOSUPPORT).

Using IPC should mean, "Tor Browser uses IPC, and only IPC", and not "Tor Browser refuses to work if non-IPC socket creation fails", because the whole point of using IPC in the first place is so that Tor Browser can be ran in a way that disallows non-IPC connections.