[tor-dev] Further sandboxing Tor Browser (aka Tor + Firejail redux).

[Yawning Angel]

I felt randomly inspired, so I spent some time poking at my firejail
Tor Browser sandboxing effort, and made progress towards something more
robust.  In particular, I switched to using AF_LOCAL (aka AF_UNIX)
sockets, via a brute force-ish approach, which seems to be working
well, despite some caveats.

In theory, this raises the difficulty of proxy bypass type things
significantly (in that you need a sandbox escape sploit to use
AF_INET/AF_INET6).  In practice, who knows, for what it's worth the
subterranean reptiloids who beam thoughts into my head from their
satellite installations reassure me that it's safer.

WARNING:

 * If you are not comfortable with running/configuring a system
   tor daemon, keeping it up to date, and keeping it in sync with the
   one shipped with Tor Browser when it diverges, stop reading, and
   wait for the Tor Browser people to come up with their own sandboxing
   solution.

 * If you expect me to provide any sort of help beyond "merging
   sensible patches", likewise stop reading, and wait for the Tor
   Browser people to come up with their own sandboxing solution.
   Really.

Prerequisites:

 * A system tor daemon with the Control port and Socks port exposed as
   AF_LOCAL sockets, with permissions configured such that the user
   running Tor Browser can write to both.  Due to torbutton quirks,
   having a SocksPort on 127.0.0.1:9050 is also a good idea, though not
   strictly necessary.

 * A recent version of firejail (nb: I did not test this with a USER_NS
   kernel.  It may be better, it may be worse.).

Setup:

 1. Clone https://git.schwanenlied.me/yawning/tor-firejail

 2. (Optional) Back up your Tor Browser install so you can go back to
    the way things used to be when you mess up.

 3. Follow the instructions in the README.md, adjusting paths as
    appropriate.  It should be self explanatory.  If it's not, revert
    back to how things were, and wait for a more official solution.

    Depending on how your tor is setup, you probably need to set a bunch
    of env vars (At a minimum, TOR_SKIP_LAUNCH is required.  Everything
    else depends on how the control/socks sockets are setup, and where
    they live, the modified start-tor-browser script has more
    documentation in comments.).

 4. Run start-tor-browser, use lsof/netstat/whatever to verify that the
    AF_LOCAL sockets are being used.

Caveats:

 * The security of this assumes that the firejail options I use to
   enforce address family restrictions work as advertised.

 * You need a system-wide tor, because if you tried to run the tor
   daemon inside the sandbox, it won't be able to access the network.

 * The firejail profile I provide disallows access to everything in the
   user's home directory except for the directory that actually
   contains Tor Browser.  Edit the profile to change this if you care
   about it.  I like the behavior for various reasons so I'm not going
   to change it.

 * The `about:tor` display falsely reports an error unless there's a
   SocksPort on 9050, due to torbutton.  You can alternatively lie to
   torbutton about where the listener is if you engage in control port
   related tinfoil hattery.

 * You need to repeat parts of the installation steps after updating.

How it works:

 * firejail's sandbox forbids all non-AF_LOCAL sockets.

 * A small stub is injected into the firefox process at runtime via
   LD_PRELOAD that fixes up socket calls to go to the system wide tor
   instance's AF_LOCAL sockets.

Random thoughts:

 * The stub should be adequate for using other similar sandboxing
   solutions (eg: flatpak's bubblewrap, Google's thing, whatever).  The
   code is compact, and is something anyone half way competent could
   write in 15 mins or so (it may have dumb bugs, dunno).   Using the
   stub on it's own without the sandbox would be a horrible idea.

 * Assuming Tor Browser works as advertised, the only reason it needs
   control port access for this sort of use case is the circuit display
   (as of torbutton commit 36d849291ec0b20a58cccc2cd846fcd2540c9bbe,
    sending NEWNYM should be unnecessary if domain isolation is
    applied to everything).

Regards,

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