[tor-dev] More tor browser sandboxing fun.
yawning at schwanenlied.me
Wed Sep 21 21:51:10 UTC 2016
On Wed, 21 Sep 2016 23:31:27 +0200
Stanisław Kosma <stanko at riseup.net> wrote:
> At this point no further audit of X11 is necessary. It is well
> understood that it is insecure by design. In fact why would you need
> an audit, take look at X11 API for yourself:
> * X11 client: Please send me all keyboard events
> * X11 server: As you wish
Indeed. This is part of it, yes.
> That does not mean that you are without options. Firejail X11
> sandboxing guide  recommends running X11 applications inside a
> separate X11 server (like Xpra or Xephyr).
If anything I'd opt to use xf86-video-nested, but really the correct
answer is "Use Wayland".
There shouldn't be anything stopping people from using a nested X
solution with sandboxed-tor-browser, since it honors DISPLAY and
writes out a new ~/.Xauthority in the sandbox tmpfs, as long as the
secondary X server puts the AF_LOCAL socket in the traditional location
> If you combine this with Flatpak or Snappy, maybe something good will
> come out of this. I would rather bet on Flatpak . It is not there
> yet, but seems to be solving right problem.
bubblewrap is the sandboxing implementation used by Flatpak, so there's
already a good amount of code reuse.
I could have opted to re-package Tor Browser as a Flatpak app, and my
launcher approach re-implements lots of functionality provided by
* I wanted to do things that required (at the time) bubblewrap git
* Flatpak has it's own install/update infrastructure. I'd rather
avoid having to repackage the bundle and updates. This way, the
only infrastructure that's used is the Tor Project stuff that
already exists, and people don't have to trust me that I did such
* Doing things this way gave me more control over the sandbox
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 801 bytes
Desc: OpenPGP digital signature
More information about the tor-dev