[tbb-dev] Sandboxing Tor Browser - Next Step

[Arthur D. Edelstein]

On Wed, Jul 25, 2018 at 9:44 PM, Matthew Finkel
<matthew.finkel at gmail.com> wrote:

Many thanks, Matt, for (re-)launching this discussion and your awesome overview!

>Specifically, we currently have four sandboxing options under
>consideration (there may be more we aren't considering):

>  a) one standard VM on all desktop OSes running Tor Browser on Linux
>  b) Per-OS container/virtualization solution
>  c) No container/vm, but sandboxing the parent and content
>     processes using OS-specific mechanisms (dropping privs etc.)
>  d) a mix of all options choosing the best per platform

It seems to me (on desktop) that the choice to be made initially is
between (a) and (d). I don't see any inherent advantage of pure (b) or
pure (c) over (d).

Option (a) seems like a radical and difficult approach, but I do think
it's worth thinking about a little more anyway. Suppose we were forced
at gunpoint to implement (a). Could we make it work? How bad would it
be? Are there big benefits?

Here are a few other things related to sandboxing that occur to me:

1. Cross-Platform Design: For Option (d), while the implementation
would be different for each platform, it would be good to have a
common cross-platform design (produced iteratively, in parallel with
implementation on at least one platform). The design would answer such
questions as: what are the set of processes we want (Broker, Launcher,
Firefox Parent, Tor, etc.)? What privileges do we want to enforce? How
do the processes communicate: what is the set of messages they pass to
one another? I think maintaining a living design document with an
explicit threat model and list of goals (and maybe non-goals) is
essential.

And then, separately, it would be helpful to track per-platform
implementation. I would suggest having a spreadsheet/dashboard, where
each row is a sandboxing feature (disk restrictions, networking
lockdown, etc) and each column is a different platform (Windows,
Linux, etc). That way we can all keep track of what the relevant
ticket numbers/patches/function names are, what is the status is
(unimplemented/nightly/alpha/stable). I'd be glad to help maintain
this spreadsheet if that seems like the right approach for organizing
this.

2. Yawning's Sandbox: Should we try to get Yawning's sandbox
production ready? (By "production ready" I mean: bundled with the
default Tor Browser download, requiring no user intervention to work,
and retaining all existing features.) There's a lot to be said for
using something that already exists instead of starting from scratch.
Getting something in the hands of users on one platform ASAP will also
provide feedback to help us with work for other platforms or even for
a follow-on rewrite of the Linux sandbox.

3. TorLauncher Problem: One significant obstacle to bringing Yawning's
sandbox to users has been the TorLauncher problem. That is:
TorLauncher is a Firefox extension that launches and controls Tor via
the control port. ideally (and in Yawning's design) we don't want
networked Firefox launching Tor or talking to its control port at all,
because Firefox is a colossal mass of potentially unsafe,
Internet-connected code. But TorLauncher is quite complex and I
believe that building a production-ready replacement is a serious
undertaking.

Possible solutions include:
 A. Remove privileges from Firefox after the existing TorLauncher runs.
 B. Run TorLauncher in its own separate instance of Firefox which is
not permitted to connect to the Internet, even via Tor. Then run
Firefox connected to the SOCKS port separately.
 C. Rewrite the TorLauncher in a safe language as a separate process
using a UI based on Qt or similar.
 D. Rewrite the back-end of TorLauncher in a safe language in a
separate process, and keep the front-end (UI) in Firefox. The backend
acts as an intermediary between Tor and Firefox to make sure only a
small set of limited operations are allowed to occur.

In any case, I think it will be helpful to have a plan early for
solving this problem (and other unsolved problems) so we don't stall
as before.

4. Named pipes: Another significant problem on Windows is that tor.exe
doesn't supported named pipes: (https://bugs.torproject.org/14209).
Apparently WIndows 10 may recently have added support for AF_UNIX
sockets, but we'd like to support other versions of Windows as well.

Possible solutions include
i. fixing tor.exe
ii. writing an intermediate process in a safe language that receives
browser connections via a named pipe and forwards data to tor.exe's
SOCKS port via a TCP socket.

5. FPI 2.0: I love the idea of trying to provide better anti-tracking
features via sandboxing. It potentially could be used not only for
fingerprinting and disk hygiene but also for First-Party Isolation.

Right now, FPI is implemented in Firefox code, mostly in the parent
process. That is: most first-party isolation of cache, cookies,
networking could be easily circumvented by a browser exploit or by an
accidental leak in the Mozilla code. We could potentially solve this
problem by launching a separate parent Firefox process for each first
party.

The "only" code needed in a grandparent process would be to implement
the UI needed across first parties. Things such as: the tabs across
the top of a window, the dimensions of the window, navigating between
sites, switching between tabs and syncing prefs.