This should answer all your questions regarding compatability with Whonix. Key points extracted for you:
Building sandboxed-tor-browser requires:
A C compiler with development libraries for Gtk+3, X11 and libseccomp2.
Go (Tested with 1.7.x)
Running sandboxed-tor-browser requires:
A modern Linux system on x86/x86_64 architecture (x86_64 STRONGLY preferred).
bubblewrap >= 0.1.3 (https://github.com/projectatomic/bubblewrap).
libseccomp2 >= 2.2.1 (x86 only, x86_64 does not require this).
Gtk+ >= 3.14.0
Where do I get bubblewrap for my distribution?
Arch Linux https://aur.archlinux.org/packages/bubblewrap-git/
Debian (jessie) https://packages.debian.org/jessie-backports/admin/bubblewrap
Debian (stretch) https://packages.debian.org/stretch/bubblewrap
Ubuntu No sufficiently recent version is available, complain to Canonical.
How do I make this use a system tor instance?
Using sandboxed-tor-browser in this way is not recommended.
A user interface based on Gtk+ is provided to control installing/updating Tor Browser and to assist in configuring the tor daemon and sandbox.
Gtk+3.0 was used despite Tor Browser linking against 2.0 to avoid the need for a future migration.
Files are placed in accordance with the XDG Base Directory specification, honoring the appropriate overrides.
Tor DataDir: ~/.local/share/sandboxed-tor-browser/tor/
Runtime files (eg: sockets): /var/run/$UID/sandboxed-tor-browser/
sandboxed-tor-browser includes the capability to download and install the latest version of Tor Browser.
Supports all of the channels and locales for a given architecture.
Supports doing the download over tor, assuming a system tor instance is present, and the TOR_CONTROL_PORT env var is set.
Also downloads the PGP signature of the bundle, and verifies it prior to installation with a hardcoded copy of the PGP key.
Modifies the bundle configuration post-install via writing out a set of configuration files using the Firefox Enterprise Deployment infrastructure.
This is needed so that the built in auto updater, and addon updating can be disabled, as the former is handled by sandboxed-tor-browser and the latter will not work by default due to filesystem permissions in the sandbox container.
sandboxed-tor-browser handles keeping the installed bundle up to date, as the bundle directory is mounted read-only inside the firefox container while the browser is actually running, precluding the ability to use the built in updater.
Checks and downloads updates over tor, launching tor in a container if required. Never uses the clear net for either.
Checks once at launch, as long as the last launch was 6 hours prior.
Independently validates the MAR signature prior to updating, with hardcoded copies of the signing keys.
Supports both full and incremental updates, favoring incremental.
Updates are done in a container with no network access, X11, or other things that are part of the firefox and tor containers.
Re-installs the config overrides after each update.
tor daemon interface
sandboxed-tor-browser can either use an existing tor daemon, or launch one in a sandbox container, and is responsible for routing traffic between the tor and firefox sandbox containers (or the system tor and the firefox container).
Interface to the system tor instance if one is configured.
Launches the tor daemon in a container with a auto-generated torrc based on the user configuration.
A SOCKS5 server that firefox talks to, that rewrites the SOCKS authentication (needed to isolate circuit/stream status information visible to the firefox process via the Tor Control Port).
A filtering Tor Control Port that firefox talks to. This provides the minimum subset of events/commands required for "New Identity" and (optionally, only if enabled) the circuit display to function.
Due to the re-writing of SOCKS5 authentication info, even if a system Tor is used, the firefox process never sees circuits or streams it is not responsible for.
When sandboxed-tor-browser launches the tor, a SOCKS5 pass-through proxy is provided at the traditional address (127.0.0.1:9150) so that the user can use other applications with the sandboxed tor daemon (nb: Some weirdness with torsocks and the pass-through proxy, needs investigation.).
Sandbox container launcher
sandboxed-tor-browser launches the various sandbox containers by fork() and exec()ing bubblewrap and passing it various arguments and static assets over pipes.
Each container is different, and will be describe in a separate section. The interface code also includes:
A seeccomp rule compiler, that accepts rules in https://github.com/twtiger/gosecco gosecco format, that produces bpf output. The actual compiler depends on architecture, x86_64 uses gosecco, i386 uses libseccomp2.
A dynamic linker cache parser (/etc/ld.so.conf) along with routines used to enumerate the libraries required from the host system inside the container for the binaries that are to be executed.
A ~/.Xauthority parser and generator, so that only the current target $DSISPLAY is exposed in the container.
Other misc routines for handling gtk+, PulseAudio, and other things.
- Circuit display is disabled;
- Users will not be able to see files e.g. those downloaded etc (by design);
- Fonts are limited to a minimal set;
- Getting sound to work e.g. Pulseaudio requires sandbox config enabling;
- “Check for Tor Browser Update” will not work manually;
- Extra addons cannot be added without changes to sandbox config (for good reason);
- Tor Browser torrc cannot be edited (tor daemon launches its own torrc);
- Plug-ins will not work e.g. Flash, Silverlight etc (by design); and
- All relevant Tor tickets can be found in this document at the bottom.