A few months ago the user Canonizing Ironize suggested:

Run tor-browser-bundle with another user

Create a new network namespace so the process only sees the local loopback device, create a read-only filesystem and mount a tmpfs with your copy of tor browser copied into it, use seccomp sandboxing (at least blacklisting if not whitelisting) to reduce the damage an exploit might do and any privilege escalation or lateral movement it might perform. You could also consider, along with these steps, using something like Xephyr or xpra to create a sandboxed X environment within your normal X environment.

Would anyone be able to put together a guide to do these exact steps in Debian/Ubuntu?

  1. Create namespace
  2. Create read-only filesystem for TBB
  3. Configure Seccomp
  4. Configure Xephyr to sandbox X

These are great suggestions. This kind of guide would great benefit many tor users. If Canonizing Ironize is still around it would be cool if he was able to contribute.

1 Answer 1


Alright, he's a hacky way I cobbled together (currently if I want a hardened environment, I use Subgraph OS which does all of this in a pretty transparent manner through Oz, it's still in beta testing but it's likely better tested than my own version, which will need some tweaking) when I run under Arch Linux, first of all it's also done from a grsec/pax kernel to frustrate exploitation and attacks against the kernel.

Update: Adding recommendations beyond Firejail because, frankly, Firejail is janky and unworthy of trust (it fails open, as an example of it's betrayal...).

Update 2: My mistrust in Firejail seems to be vindicated by various vulnerabilties that result in privilege escalation. Luckily, Yawning's sandbox code is now in alpha testing, what it provides can be read here and the code is here. As such I'm removing all firejail documentation.

One of the Tor Developers is working on creating a sandbox for Tor Browser based around a lot of these principles and technologies, except it's going to be better and less hacky than my script below but probably not as extensive as Subgraph or Qubes.

There is Q&A about Yawning's Bubblewrap Tor Browser sandboxing efforts available here and the code for the sandboxing tool is here.

Yawning's code is now released, it creates two sandbox environments. One for Tor Browser and another for the Tor daemon. It handles downloading and verifying the Tor Browser, as well as updating it.

Note that this doesn't address the issues of lateral movement within an X session (any X application can access any other application within the same X session), so you may wish to take extra steps like using Xephyr or xpra to run a nested X instance to launch the browser inside.

Google also recently gave a talk at a Linux conference about a similar tool they produced to lock down service daemons on Chrome OS, called minijail which also utilises many of the same features of modern Linux kernels.

Arch Linux has a tool called playpen available from the community repos, which works with similar ideas but from inside a chroot, maintained by one of the Copperhead developers.

Other things to consider

  1. Using a Control Port filter to block the majority of functionality of the control port from Tor Browser.
  2. Using a nested X instance.
  3. Using a hardened kernel.
  4. Using a paravirtualized virtual machine to reduce hardware fingerprinting.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .