On Wed, Jul 25, 2018 at 9:44 PM, Matthew Finkel matthew.finkel@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.