Hi,
Note:
* Don't use this unless you are capable of debugging it. * Don't use this if you need strong security (though the author believes it is an improvement over unsandboxed Tor Browser, and the previous sandboxing attempts). * Don't re-package it, it's not ready for that.
In addition to stewing in my infinite self-loathing, I made a serious attempt at sandboxing Tor Browser again. It works, is kind of neat, and isn't totally horrible, so I'm showing what's available.
Where: https://git.schwanenlied.me/yawning/sandboxed-tor-browser
This builds a lightweight launcher process that will:
* Handle installing/updating Tor Browser, while being rather paranoid about having a good trust root (hard copies of PGP keys, the update service's cert chain, and the MAR signing key are included and enforced).
* Run the updater in a sandboxed environment without network access.
* Run Tor Browser in a sandboxed enviornment with the Tor SocksPort being the only way to get beyond the host.
There's a bunch of caveats, and some functionality that's intentionally broken, and certain annoyances that require a Tor Browser patch or two to fix, but it appears to work fairly well.
The README.md file has more detailed documentation on how it works, the sandbox environment, and the various caveats.
On Wed, Sep 21, 2016 at 5:33 AM, Yawning Angel yawning@schwanenlied.me wrote:
Where: https://git.schwanenlied.me/yawning/sandboxed-tor-browser
X11 is a huge mess of utter fail. Since the sandboxed processes get direct access to the host X server, this is an exploitation vector.
Is anyone actually actively throwing the full audit gamut at X11 these days, or is it still just one giant pile of 30 year legacy waiting to explode?
Really, just fuck off and leave me alone.
Oh no, the concept of one toplevel sig over a pile of embedded sigs and infrastructure underneath, is useful. Kindof like how signing a monotone or git repository is useful... a single and simply checkable root from which all crap piles floweth.
On 21.09.2016 19:57, grarpamp wrote:
On Wed, Sep 21, 2016 at 5:33 AM, Yawning Angel yawning@schwanenlied.me wrote:
Where: https://git.schwanenlied.me/yawning/sandboxed-tor-browser
X11 is a huge mess of utter fail. Since the sandboxed processes get direct access to the host X server, this is an exploitation vector.
Is anyone actually actively throwing the full audit gamut at X11 these days, or is it still just one giant pile of 30 year legacy waiting to explode?
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
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).
Additionally there are at least two display servers that took security a little bit more seriously, i.e., Wayland and Mir. 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.
[0] https://firejail.wordpress.com/documentation-2/x11-guide/ [1] https://github.com/flatpak/flatpak/wiki/Sandbox
On Wed, 21 Sep 2016 23:31:27 +0200 Stanisław Kosma stanko@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.
There is VM's, and Multiple X server can isolate on up to all available vty's. There is also program shipped by X11 called Xnest. But the more concern than apps and keyboards above, is probably the driver / kernel portion of security surface.
On Wed, 21 Sep 2016 21:51:10 +0000 Yawning Angel yawning@schwanenlied.me wrote:
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.
Yep, Xephyr "just works", assuming you make sure to add a `MIT-MAGIC-COOKIE-1` credential for it to the Xauthority file. For convenience I added an option to the config file to override the DISPLAY env var that sandboxed processes see.
It works ok, but isn't for me, because copy and paste between the parent and nested X session is a huge pain.
I briefly considered adding an option to auto-start the nested X server, but certain aspects of the Firefox UI break without an window manager.
Regards,
-
grarpamp -
Stanisław Kosma -
Yawning Angel