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,
I think this could be wrong:
TOR_CONTROL_COOKIE_AUTH_FILE=/var/run/tor/control_auth_cookie
Debian /usr/share/tor/tor-service-defaults-torrc uses: CookieAuthFile /var/run/tor/control.authcookie
Common paths are: - /var/run/tor/control.authcookie - /var/lib/tor/control_auth_cookie
I suggested to standardize the path and to settle down on /var/run/tor/control.authcookie since more correct location for an ephemeral file.
'set Tor Control Authcookie default file location from /var/lib/tor/control.authcookie to /var/run/tor/control.authcookie'
https://trac.torproject.org/projects/tor/ticket/19572
Cheers, Patrick
On Fri, 22 Jul 2016 15:20:00 +0000 Patrick Schleizer patrick-mailinglists@whonix.org wrote:
I think this could be wrong:
TOR_CONTROL_COOKIE_AUTH_FILE=/var/run/tor/control_auth_cookie
That block was supposed to be in a bunch of if statements. Fixed. The default path that gets set is unchanged.
Debian /usr/share/tor/tor-service-defaults-torrc uses: CookieAuthFile /var/run/tor/control.authcookie
So? I don't use Debian for development.
Common paths are:
- /var/run/tor/control.authcookie
- /var/lib/tor/control_auth_cookie
I write software for me, default configs will continue to reflect how my development environment is setup.
I assume people can use setenv/export to override it, or if it bothers them that much, use vi/nano/pico/ed/ex/emacs/xemacs.
As a side note, there's zero real reason for this particular env var to exist at all (See #16017), beyond "no one has cared enough to write what should be a simple branch".
Regards,