Hi Everyone,
We had a productive meeting yesterday about sandboxing Tor Browser. I sent a high-level summary on tor-dev@ [0]. We ended the meeting while we were discussing/considering the different criteria for how we decide which sandboxing implementation(s) we persue [1]. This is the continuation of that topic.
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
With each of these mechanisms, we enumerated some criteria for evaluating them and choosing the best option for Tor Browser:
1) (in the face of a browser exploit) tracking protection 2) (no browser exploit) tracking protection 3) (in the face of a browser exploit) proxy bypass protection 4) (no browser exploit) proxy bypass protection 5) user experience 6) development effort (including time to market with improved security) 7) maintainability 8) uplift possibilities 9) installation size? (part of user experience?) 10) ability to take advantage of expected future security improvements 11) Compatibility with future browser/app development plans at the Tor Project
As mentioned during the meeting, there doesn't currently exist a common set of sandboxing mechanisms across all platforms. Maybe this will exist in some years when Docker is the de facto standard run-time. Until then, we have platform-specific implementations we must use.
How should we document ranking each of the sandboxing options with the stated criteria? Would this be easier on another pad or using a spreadsheet (ethercalc)?
Thanks, Matt
[0] https://lists.torproject.org/pipermail/tor-dev/2018-July/013350.html [1] https://pad.riseup.net/p/sandbox-07-24
On Wed, Jul 25, 2018 at 9:44 PM, Matthew Finkel matthew.finkel@gmail.com wrote:
How should we document ranking each of the sandboxing options with the stated criteria? Would this be easier on another pad or using a spreadsheet (ethercalc)?
Before we do this in earnest (because it's probably a week of person-work or more) - do we need to?
Georg had indicated some affinity to (d).
I think (d) certainly has the flexibility to give us the best security-usability-tradeoff on all platforms. (What I mean by that is "Running Tor browser on Linux in a VirtualBox container on Windows" (aka (a)) is certainly a more secure solution than (c) - but it's also going to be a bad user experience.) The major detriments of (d) as I see them are costs on maintainability and difficulty of uplift depending on the solution we pursue on each.
All in all, I'm quite happy with (d).
-tom
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.
On 07/30/2018 01:39 PM, Arthur D. Edelstein wrote:
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
The correct answer is "d", with Linux taking the "b" route.
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?
It could be made to "work", but it would be fairly horrible:
* On potatoes pretending to be computers. * For people that have limited bandwidth to download a full VM image. * The UI/UX will be a nightmare to get right (How will files work?) * Updates would be a nightmare to get right.
If people are unconvinced about this, they are welcome to find a suitably low end potato (eg: an Atom netbook with 1 GiB of RAM), and use Tails in Virtual Box on Windows as as their sole Web Browser for a week.
- 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.
This would be a bad idea. There's quite a bit of additional work that would need to go into it to make it non-technical people ready, with the big ones being:
* The UI is a ugly knockoff of the TorLauncher UI, and the code is worse, and it sucks to maintain. * A non-trivial amount of development time would need to be spent making 8.0 work properly. * There are a large number of unresolved issues including but not limited to:
1. Being able to type in more than English. 2. Better integration with the Tor Browser interface, particularly relating to updates and configuration. 3. Supporting more than the transports provided by obfs4proxy. 4. No work has been done regarding the bridge auto-discovery, because that started going in when I basically gave up on the project, due to not wanting to have to write UI code for the rest of my life. 5. Probably other things, that I forgot about.
- 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.
C or D, with C being "better". A is hard and OS specific. B is a nasty kludge that wants to be D when it grows up.
Regards,
-
Arthur D. Edelstein -
Matthew Finkel -
Tom Ritter -
Yawning Angel