1281296 - Allow running Firefox with Internet access disallowed at the OS level

Status: NEW

(Core :: Security: Process Sandboxing, defect)

Description

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

This bug proposes support for running the entire Firefox browser with all Internet access prevented; this is for use with bug 1211567, to have it use a Unix-domain socket (or equivalent on Windows?) to connect to a local anonymizing proxy like Tor, to increase the level of assurance that all network traffic is in fact routed through the proxy.

The threat model here does *not* include code execution exploits, only code already within the browser (and libraries it loads) that might be tricked into sending Internet traffic outside the proxy.

On Mac, this should be fairly straightforward to implement using the OS X sandbox policy language.

On Linux, we have a few tools, none of which are perfect:

1. Unsharing the network namespace will give the process (and any descendents) its own network stack with its own private loopback interface and no others.  This requires unprivileged user namespaces, which still has some availability problems due to security concerns about the feature itself, as well as older kernels.  (Note: normal named Unix-domain sockets aren't affected by this — they follow filesystem path semantics instead — but the Linux-specific “abstract namespace” is.)

2. seccomp-bpf can prevent socket() calls in the AF_INET or AF_INET6 domains (or anything other than AF_UNIX), except on 32-bit x86 (before kernel 4.3) where socketcall() means either blocking socket() entirely or not at all.  Unless we can connect to the proxy once at startup and then never lose that connection, we'll need to allow socket() in AF_UNIX on an ongoing basis.  An unsandboxed helper process or thread could be used to work around that problem.  (Also, this has implications for bug 1257361.)

3. ELF symbol interposition has no kernel requirements, but won't catch anything that makes syscalls directly instead of using normal dynamic linkage against libc.

Note that several of these could be stacked for defense in depth.

On Windows, this is apparently still an open question.  (And not even remotely my area of expertise; information welcome.)


Also there are some startup order issues:

* Some of the Linux things need to happen when single-threaded, but if we're reading a pref to find out whether this should happen, there might already be threads by that point?

* If Firefox itself is spawning the proxy (as opposed to a wrapper script or OS service manager), that will need special handling or else the proxy will inherit the Internet access prohibition, which will make it not work.

And, on Linux, using libmozsandbox in the "firefox" executable (to share code with the child process sandboxing) has some annoying build issues; see bug 1277968 and bug 1268733.

Comment 1

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

The closest thing to a proof-of-concept I have right now needs root, as follows:

  sudo unshare -n -- sudo -u `whoami` ./mach run

And that works.  But if I try to unshare the network namespace by using an unprivileged user namespace, the GPU drivers crash the compositor thread somewhere inside the Mesa/Gallium state tracker.  It's possible that something is getting confused by the effects of the new user namespace (basically, anything that isn't the process's own euid/egid reads as nobody/nogroup, including the process's own secondary groups, but the actual credentials are unchanged); if so, I'm at a loss for how that might relate to the actual crash.

To try this out without having Tor set up, I did this:

  socat UNIX-LISTEN:/tmp/testsock,fork TCP:localhost:1080 &
  ssh -v -D1080 (somewhere)

Also, know that the proxy pref UI requires a non-zero port number to go with the SOCKS “host” even if it's a file:/// URL, but it seems to be ignored otherwise.

Comment 2

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

`unshare -Un firefox --new-instance` works for me now, as does running in an unprivileged user namespace mapped to the original uid/gid, so something changed between comment #1 and now but I don't know what.

Specifically, both hardware-accelerated compositing and WebGL work, either with Intel+Mesa or NVIDIA drivers, so that should cover whatever caused the crashes I mentioned.

In any case, it's now possible (at least on some distributions) to run Linux Firefox without direct network access and without needing root privileges to install something like bubblewrap.

(Disclaimer: Firefox can still communicate with other processes, through named Unix-domain sockets and/or files, so it's possible that it could indirectly cause network access somehow, but simple proxy bypasses should be ruled out by this.)