future SocksSocket and sandboxing

[adrelanos]

Recent changes (SocksSocket [Tor Browser version 6.5.a4 and above] and sandboxing) in Tor Browser by The Tor Project have a good chance to break qubes-split-browser in its current form.

more references on SocksSocket:
https://forums.whonix.org/t/tor-browser-6-5a4-connectivity-broken-blocked-by-apparmor-profile-since-tbb-changed-to-sockssocket

more references on sandboxing:
https://forums.whonix.org/t/tor-browser-sandbox-linux-alpha-coming-soon

[rustybird]

Thanks for the links! In the short term, I'd probably just revert to Socks over TCP.

In the long term, the goal is Socks over qrexec. A tiny adapter script on the gateway would receive incoming qrexec connections from e.g. disp23 and connect them via socat to 127.0.0.1:9150, with a source address of 127.0.0.23 to get per-VM circuit isolation. I don't know if R4.0 qrexec-policy can already express the policy "automatically allow any dispVM launched by browser-1 to connect to adapterService on sys-whonix". Probably not yet...

[adrelanos]

Rusty Bird:

Thanks for the links! In the short term, I'd probably just revert to Socks over TCP.

If that is possible without recompiling Tor Browser. One development goal of The Tor Project was to compile Tor Browser without TCP/IP. Dunno if that is yet implemented.

[rustybird]

One development goal of The Tor Project was to compile Tor Browser without TCP/IP.

Crap, I didn't think of that. Do you know when this feature is supposed to hit the stable non-hardened branch?

---

Anyway... I'm actually posting this comment from an offline DispVM via Socks-over-qrexec!

/etc/qubes-rpc/tbSocks.GatewayAdapter in sys-whonix:

#!/bin/bash

[[ $QREXEC_REMOTE_DOMAIN =~ ^disp([0-9]+)$ ]] &&
exec socat - TCP4:127.0.0.1:9150,bind=127.0.1.${BASH_REMATCH[1]} 

tbsocks-client-adapter.service (enabled) in my debian-8 DispVM template:

[Unit]
Description=Tor Browser Socks/qrexec client adapter
Conflicts=rinetd.service

[Service]
ExecStart=/usr/bin/socat TCP4-LISTEN:9150,bind=127.0.0.1,reuseaddr,fork 'EXEC:qrexec-client-vm sys-whonix tbSocks.GatewayAdapter'

[Install]
WantedBy=multi-user.target

/etc/qubes-rpc/policy/tbSocks.GatewayAdapter in dom0:

disp66 sys-whonix allow

And finally, /etc/split-browser/persist/prefs.js.d/20-whonix-gateway.js removed from my Split Browser persistent VM.

Seems to work fine, though latency is a little higher.

[rustybird]

^ Updated tbSocks.GatewayAdapter use port 9150 in sys-whonix

[adrelanos]

Rusty Bird:

> One development goal of The Tor Project was to compile Tor Browser without TCP/IP. Crap, I didn't think of that.

I guess it will not be a show stopper. The implementation of the anon-ws-disable-stacked-tor package is not rocket science. [Whonix stable upgrade coming in a few days, currently in Whonix jessie-proposed-updates and testers repository) Tor Browser allows TCP and control sockets to be set to specific unix domain socket file through environment variables. socat can create such unix domain socket files and redirect them anywhere as TCP (what we do in Whonix, anon-whonix -> sys-whonix) or unix domain socket. So either way, I guess you'll find a solution.

Do you know when this feature is supposed to hit the stable non-hardened branch?

It will be in the next major stable Tor Browser release. Not sure if that answer helps. I don't follow exact dates, since I make sure that alphas work in Whonix and by the time they flow into stable they are already tested.

*** Anyway... I'm actually posting this comment from an offline DispVM via Socks-over-qrexec!

Nice!

[rustybird]

extensions.torlauncher.socks_port_use_ipc has been set to false as a short term fix. Maybe Socks-over-qrexec will be good enough by the time they remove TCP support.

(Lots of thanks for the heads up! I solemnly swear to always test the TB alphas from now on.)