On Wed, 21 Sep 2016 23:31:27 +0200 Stanisław Kosma <sta...@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
pgp3SdAZl2YPc.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
