Tor Browser Sandbox (Linux Alpha) - Coming Soon


Looks like no help is forthcoming for Bug 21076:


I don’t see myself being able to reproduce this to debug it. If there’s root cause diagnosis of why this happens, or patches that would be helpful. I also don’t have the time to make all the bits that talk to the control port play nice with something that is out of spec.

So, the Whonix work-around step can be (somewhere):

Testers may find the sandboxed-tor-browser fails to start on the first or second try, due to a broken system control port. The workaround is to run:

rm -r .config/sandboxed-tor-browser

Re: Bug 21077


Yawning has replied that it relates to the Jessie Bubblewrap version?

This looks like bubblewrap being broken on whatever platform this is. If that’s the case, then there isn’t much I can do about it.

What does bwrap --ro-bind / / --proc /proc --dev /dev /bin/bash say.

You said the system tor process is automatically detected. Didn’t you have to make manual config changes to use the system tor process with this info from Yawning’s wiki?

How do I make this use a system tor instance?

Using sandboxed-tor-browser in this way is not recommended.

TOR_CONTROL_PORT=9051 sandboxed-tor-browser

TOR_CONTROL_PORT=tcp:// sandboxed-tor-browser

TOR_CONTROL_PORT=unix:///var/run/tor/control sandboxed-tor-browser

Let me try and summarise correct steps required for this sandboxing testing, check with you, then run it in a cloned template of Whonix-WS which is upgraded to Whonix 14 dev work.


No, because TOR_CONTROL_PORT=9151 already is an environment variable.

You can check that by running:

env | grep TOR

Btw can also be interesting to see all environment variables.


Setting TOR_CONTROL_PORT=9151 might be considered a Whonix bug at some point. (When the Tor Browser 5.0x series are deprecated and 5.5x series requiring SocksSocket. For now TOR_CONTROL_PORT=9151 is required to stay compatible with Tor Browser 5.0x series.

  • TOR_CONTROL_PORT=9151 could be in conflict with
  • TOR_CONTROL_IPC_PATH=/var/run/anon-ws-disable-stacked-tor/

TOR_CONTROL_IPC_PATH=/var/run/anon-ws-disable-stacked-tor/ works with Tor Browser 5.5x series. At some point TOR_CONTROL_PORT=9151 might break Tor Browser (when TCP gets removed from Tor Browser). The bug here might be sandboxed-tor-browser support
TOR_CONTROL_PORT=unix:///var/run/tor/control sandboxed-tor-browser vs leaving that to TOR_CONTROL_IPC_PATH.


Same startup issue on the following platforms.

  • Qubes Debian amd64 jessie TemplateBased AppVM (with golang bubblewrap libseccomp2 libseccomp-dev from jessie-backports)
  • Qubes Debian amd64 stretch TemplateBased AppVM (with golang bubblewrap libseccomp2 libseccomp-dev)

reported here:

Can you try in a Non-Qubes Debian VM?


Works for me in a Non-Qubes Debian jessie VM (with the packages from jessie-backports).



As per https://trac.torproject.org/projects/tor/ticket/21048 also the following dependencies need to be installed.

sudo apt-get install gnome-themes-standard gnome-themes-standard-data

Whonix VirtualBox:

works out of the box. Network settings are auto detected as system Tor just fine. No need to configure network settings. Just start it using:


(i386 version.) (amd64 version / Tor Browser hardened has to wait until Non-Qubes-Whonix 64 bit downloadable images are available. [Status of Whonix 32 bit vs 64 bit]



Sorry, I took the rest of Christmas day off!

Well, your instructions are clear for getting this working in non-Qubes-Whonix, so I can write something up for that and check with you before editing the wiki stub.

There is something obviously wrong in the Qubes-Whonix environment though, so I think we can just note that this is ‘blocked’ pending resolution of Qubes Issue #2540.

This is a real bummer, because with over 600 issues, this may not be solved anytime soon. Or, bubblewrap may have some incompatibility with the Qubes environment.

Thus, Qubes-Whonix users may need to resort to the inferior Firejail as an interim sandboxing work-around, until instructions in that other thread is sorted out and tested.


Sandboxing Tor Browser in Non-Qubes-Whonix

Warning: These instructions are extremely alpha. They currently only work reliably with the 32-bit version of Whonix. Testers or advanced users only![1]


A sandbox is a secure environment in which you can run the Tor Browser and mitigate exploit vectors which would otherwise deanonymize you or infect your computer. In essence, the Tor Browser is run in a limited awareness container that is prevented from interacting with the rest of your computer.

Sandboxing reduces the opportunities for an attacker to easily identify real IP and MAC addresses, install malware, browse your files or otherwise deanonymize you.[2] A spate of recent attacks on the Tor Browser in the wild suggest this is a prudent approach for cautious users, or those facing significant risks.

The Tor Browser sandbox is compatible with either the “release”, “alpha” or “hardened” Tor Browser series. However, the sandboxed “hardened” Tor Browser is the least-tested combination by Tor developers.[3]

Sandboxing Effects on Tor Browser Functionality

While sandboxing improves security, some functionality is lost either by design or inadvertently. In addition, some functions like sound must be optionally configured. As of December 2016, broken items include:[4]

  • Foreign language support;
  • The meek pluggable transport; and
  • Manual checks for Tor Browser updates.

The Tor Browser sandbox is unlikely to ever support:

  • The FTE pluggable transport;
  • Hardware-accelerated 3d rendering;
  • Printing, except to a file;
  • Connections outside of the Tor network; and
  • Compatibility of the “hardened” Tor Browser with a grsec kernel (due to ASAN/Pax conflicts).

Audio support, the Tor ciruit display and installing or updating Tor Browser addons also require manual configuration changes.[5]

Tor Browser Sandbox Dependencies

In order to install and run the sandbox, two things are required:

  • Several dependencies available in Debian Jessie backports; and
  • A newer (Whonix-14-developers-only) version of the control-port-filter-python for Tor cookie control protocol authentification.[6]

Installing sandboxed-tor-browser Dependencies

(1) Boot your Whonix-Workstation TemplateVM

(2) Enable jessie-backports

sudo su -c “echo -e ‘deb http://http.debian.net/debian jessie-backports main’ > /etc/apt/sources.list.d/jessie-backports.list”

OR to use the .onion mirror

sudo su -c “echo -e ‘deb http://vwakviie2ienjx6t.onion/debian jessie-backports main’ > /etc/apt/sources.list.d/jessie-backports.list”

(3) Use apt-pinning before installing dependencies[7]

Open /etc/apt/preferences.d/debian-pinning.pref in an editor with root rights.

If you are using a graphical Whonix, run:

kdesudo kwrite /etc/apt/preferences.d/debian-pinning.pref

If you are using a terminal-only Whonix, run:

sudo nano /etc/apt/preferences.d/debian-pinning.pref


Package: *
Pin: release a=stable
Pin-Priority: 700

Package: *
Pin: release a=jessie-backports
Pin-Priority: 650

Package: *
Pin: release a=testing
Pin-Priority: 600

Package: *
Pin: release a=unstable
Pin-Priority: 550

Package: *
Pin: release a=experimental
Pin-Priority: 500


(4) Update your package lists and install sandboxed-tor-browser dependencies

sudo apt-get update

sudo apt-get -t jessie-backports install golang bubblewrap libseccomp2 libseccomp-dev

(5) Install additional dependencies[8]

sudo apt-get install gnome-themes-standard gnome-themes-standard-data

Installing the Whonix-14 tor-controlport-filter[9]

Note: This process must be repeated on both the Whonix-Gateway and Whonix-Workstation.

(1) Upgrade to the Whonix-14 work in progress

sudo whonix_repository --baseuri https://deb.whonix.org --enable --repository developers

sudo su
export DEBDEBUG=1
export tpo_downloader_debug=1

apt-get update

find . /var/lib/apt | grep -i inrelease | xargs cat

apt-get --yes dist-upgrade

apt-get --yes autoremove

(2) Test the tor-controlport-filter is working

In the Whonix-Gateway run:

nc 9051

Type “something”. You should see the reply:

510 Command filtered

In the Whonix-Workstation run:

nc 9151

Type “something”. On the gateway you should see some tor-controlport-filter by Tails debug output.

Downloading the Tor Browser Sandbox

(1) Download the sandboxed-tor-browser binaries and signing key from the Tor Project[10]

In the Whonix-Workstation VM run:

wget https://www.torproject.org/dist/torbrowser/6.5a6/sandbox-0.0.2-linux64.zip

wget https://www.torproject.org/dist/torbrowser/6.5a6/sandbox-0.0.2-linux64.zip.asc

(2) Download the Tor Project signing key and verify the zip file


gpg --recv-keys “EF6E 286D DA85 EA2A 4BA7 DE68 4E2C 6E87 9329 8290”

gpg --verify sandbox-0.0.2-linux64.zip.asc

(3) Unzip the sandbox


unzip sandbox-0.0.2-linux64.zip

Using the sandboxed-tor-browser

To start the sandbox, simply run:


And select the Tor Browser version you are currently using in your Whonix-Workstation configuration.


  • sandboxed-tor-browser is also a Tor Browser downloader similar to tb-updated / torbrowser-launcher;
  • Whonix network settings are auto-detected as system Tor and there is no need to configure settings manually; and
  • If you wish to check the sandboxed-tor-browser is correctly using the system Tor process anyhow, in a terminal run:

env | grep TOR

The output should show:


is set as an environment variable.

Sandboxing Tor Browser in Qubes-Whonix

To Do.

The Tor Browser alpha sandbox is currently blocked in both the Qubes Debian and Qubes-Whonix Templates due to problems with bubblewrap.[6][11][12][13][14]

A recommended interim solution is to use Firejail in Qubes-Whonix to better contain the Tor Browser application.[15]


[1] These steps can be modified slightly to work in a (non-Qubes) Debian Jessie VirtualBox VM
[2] https://blog.torproject.org/blog/q-and-yawning-angel
[3] https://blog.torproject.org/blog/tor-browser-65a6-hardened-released
[4] https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Sandbox/Linux Some of these bugs will be fixed at a later date.
[5] The Tor circuit in Tor Browser is disabled by default in Whonix anyhow
[6] Tor Browser Sandbox (Linux Alpha) - Coming Soon
[7] For safe mixing and matching of packages from different Debian repository branches without breaking your base distribution
[8] https://trac.torproject.org/projects/tor/ticket/21048
[9] https://www.whonix.org/wiki/Dev/Control_Port_Filter_Proxy#tor-controlport-filter_by_Tails
[10] https://www.torproject.org/projects/torbrowser.html.en#downloads-alpha
[11] https://trac.torproject.org/projects/tor/ticket/21077
[12] https://github.com/QubesOS/qubes-issues/issues/2540
[13] https://github.com/projectatomic/bubblewrap/issues/134
[14] Apparmor and grsec have been ruled out as blockers. Upgrading to Debian Stretch in the TemplateVM in Qubes does not work, nor does changing the Debian VM dom0 kernel via pvgrub
[15] To do: insert wiki reference to Firejail entry when complete





Stop building 32 bit sandboxed-tor-browser binaries.

Since I merged #20940, x86 support has been deprecated, and binaries for that platform should no longer be built.


The wiki entry is done and is awaiting a reviewer to approve it.



Doing some nitpicking on top.

Please don’t copy and paste from wiki templates. The goal is to avoid text duplication. The beauty of wiki templates is, that only the text in the wiki template needs to be changed.

Done here:

Duplication / manual copy and paste generally should be avoided. Otherwise when instructions change, we have to change them in X locations. And if these instructions derivate in two places, we end up with two users claiming to have done the same thing, but actually another thing. So replaced the upgrading to Whonix 14 developers-only instructions with a link to these. (We could make that a template, but well.)

Done here:

Lastly, please don’t use footnotes inside = titles =, since then the anchored links look bad.

These are just minor things. None of this speaks against directly editing the wiki, since these are easily sorted out on top.



We need to revisit the dependencies in the wiki.

Ever-helpful advice below :wink:


On January 3rd, 2017 Anonymous said:

Working instructions for non-Qubes-Whonix using the available binaries is below. This should also work with other platforms with minor changes:


Sandbox is not working in Qubes-Whonix due to problems (unresolved) with bubblewrap, see here:


Even the bubblewrap and Qubes developers are mystified, since the Qubes kernel is very similar to upstream kernel.

Yawning, does this info help to further investigate that Tor Ticket re: “Can’t mount proc on /newroot/proc: Operation not permitted”?


On January 3rd, 2017 yawning said:

At a glance, those instructions are pulling in unneeded dependencies (there is a difference between build and run-time dependencies for the project). But I don’t use Qubes-Whonix at all, or Debian for that matter so I can’t really comment on the rest of it.

Hmm. Revisiting:


Now shows:


Building sandboxed-tor-browser requires:

A C compiler with development libraries for Gtk+3, libnotify, and X11.
gb (​https://getgb.io/)
Go (Tested with 1.7.x) 


Running sandboxed-tor-browser requires:

A modern Linux system on the x86_64 architecture.
bubblewrap >= 0.1.3 (​https://github.com/projectatomic/bubblewrap).
Gtk+ >= 3.14.0
(Optional) PulseAudio
(Optional) The Adwaita Gtk+-2.0 theme (Install gnome-themes-standard on Ubuntu).
(Optional) libnotify 

Since we are grabbing the binaries, don’t we only need to pull in bubblewerap from Jessie backports for our instructions and maybe the Adwaita theme? That is, golang is only needed for manual builds (scrap it)?

What about the libseccomp2 and libseccomp-dev dependencies - why did we require that? Whonix-14 requirement?

It’s notable that Yawning doesn’t use Qubes or even Debian. You’d think someone paranoid about computing wouldn’t default to other Linux VM solutions.

Heaven forbid he/she assumes the monolithic (huge) Linux kernel is trustworthy or secure in any other general purpose distro, since we are looking at 10s of millions of lines of code in the kernel these days.

Joanna notes that it is impossible to ever secure the computing base of something so large and full of 1000s of undiscovered coding errors. Thus, it is only safe to assume future compromise and run compartmentalized solutions and isolation of dangerous elements e.g. USB, GUI, networking -> hence Qubes’ evolution.


Can you try please which dependencies are unnecessary? The thing is - with the dependency it starts - without - it does not start.

I don’t think there is a middle ground aka “missing dependency - starts - think you are using bubblewrap - but surprise, it is ineffective”.



I don’t have extra hardware to be able to test this unfortunately, nor do I run dual-boot systems due to their inherent insecurity. I think @HulaHoop is running plain non-Qubes-Whonix, perhaps he could help check the dependencies on a cloned template?

If not, I suppose it doesn’t really matter, since all it means is some extra software is being pulled in that is not being used, and you have already successfully tested this…


Some really great progress wrt bubblewrap in Qubes in the ticket.



To translate it, I think the following is the only additional command one has to run before being able to run bubblewraped Tor Browser in Qubes.

sudo umount /proc/xen



That’s great!

So, can Qubes-Whonix users just follow the instructions here:

with an additional step of:

sudo umount /proc/xen

before launching with:



Let me know, and I can trial this for you ASAP, as I’m dying to run this sandbox in Qubes. I’d love to also run it in a Whonix-WS dispVM successfully. I can also check the dependencies stuff at the same time.

PS I’m holding off on grsec testing on Whonix templates, as Coldhak is definitely working on it currently. So there is some reason why it is separate work, otherwise they would have recommended the same steps as per the Debian-8 Template. Unless you have it working already in your set-up?

Debian-8 coldkernel is running like a dream though. Very stable.