Sandboxing Tor Browser is complicated and difficult. The current state of sandboxing reduces the usability of the web and web browser. We only have sandboxing implementations on Linux and Mac OSX, at this time.
There are trade-offs when using the sandboxed Tor Browser:
| Platform | OS Requirements | App Naming | Filesystem Access | Tor Control Port | Firefox Updater | Audio Support | Pluggable Transports | 3D Hardware Accel | Printing | Firefox Add-ons |
|---|---|---|---|---|---|---|---|---|---|---|
| Linux | [[https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Sandbox/Linux#Runtime | Requires]] | N/A | New namespace | Launcher but not Firefox | Via launcher, not built-in Firefox | Opt-in | Some broken (meek, fte) | only software rendering | Only printing to file |
| Mac OSX | OSX 10.9+ (additional profiles needed for earlier versions) | Must be named TorBrowser.app | Unix domain sockets in /tmp/Tor | Full | None | Yes | Yes? | Yes? | Yes? | Yes? |
Notes: While researching existing launcher sandboxing binaries and libraries, many exist but somehow none are as fully-featured as we need.
- Preliminary Windows Container Support
- Some subset of Unix-like platforms
We can likely use pieces of some of these (respecting their licenses).
Possible sandboxing techniques:
Android
- GeckoService runs in isolated process (no permissions environment)
- All Necko connections are proxied by a dedicated networking service over a Binder instance
- this is sadness because Binder is message-based, not stream-based
- All networking calls must use Necko
- Implement seccomp-bpf
- Android permissions model restricts FS access within app-local profile
- Device-access is permissions based, but can we expire permissions after some time?
- I believe the answer is "no", there is no way of dropping a permission the user already granted
Linux
- We can follow many of the design choices used by https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Sandbox/Linux
- Launcher process creates sandboxes
- Require bubblewrap
- strict(ish) seccomp-bpf
- Isolated namespaces
- Only bind mount the files/dirs required
- No /proc or /sys or ...
- Tor runs in a namespace isolated from Firefox
- Launcher process handles updating Tor Browser
- The launcher process can provide privileges access over Tor and Firefox
- As an example, we can implement a "Copy File" helper in the launcher that copies a file into the Firefox sandbox or out of the Firefox sandbox and into a user-selected location
- Reduce X11-sadness (proxy? https://gitweb.torproject.org/tor-browser/sandboxed-tor-browser.git/tree/src/cmd/sandboxed-tor-browser/internal/sandbox/x11/surrogate.go, https://www.qubes-os.org/doc/gui/)
- Any risks we should mitigate on wayland?
- Circuit display can be isolated within its own sandbox, accepting no input, and only receiving filter controller events
- Can we provide printing somehow?
- IBus-based language input methods? (#20774)
Mac OSX
- Apple are deprecating the Seatbelt profile (but there isn't a good alternative for fine-grained, runtime, per-process isolated sandboxing)
- The Seatbelt profile must be updated (created: #20121, removed: #26438 (closed))
- One main challenge is the how we handle creating the sandbox while continuing to effectively use Firefox's current sandbox (ticket:22000#comment:7)
- Use privileged launcher process (similar to Linux)
- Deny all TCP/UDP
- See also: Chromium analysis on sandboxing their parent/browser process