[tor-dev] More tor browser sandboxing fun.

Yawning Angel 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 [0] 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
under /tmp.

> If you combine this with Flatpak or Snappy, maybe something good will
> come out of this. I would rather bet on Flatpak [1]. 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
Flatpak, however:

 * I wanted to do things that required (at the time) bubblewrap git
   master.

 * 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
   things correctly.

 * Doing things this way gave me more control over the sandbox
   environment.

-- 
Yawning Angel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160921/61b5f51e/attachment.sig>


More information about the tor-dev mailing list