Keeping the full quote to share it on qubes-devel. William Budington: > Hey all, > > I'm using whonix from within Qubes. I'm trying to find a way to > remove the tor ports as an attack surface from the whonix-ws while > still maintaining circuit isolation for applications run within > workstations. Currently, I see that the tor ports are forwarded from > the whonix-gw via rinetd. > > Possible solution: a piece of software intended to be used on > whonix-gw which opens one network interface per circuit, and > provisions an arbitrary number of VMs with circuit-isolated, > transparently torified connections without exposing the tor > socks/control ports to them. That way you could run one application > per VM which is on an isolated circuit, but has no access to the tor > ports. Does anything like this currently exist? > > Obviously this would be a bad solution for the Tor Browser, which > relies on access to the tor ports to do per-tab isolation. But I > figure it would be an okay solution for other applications that do > not rely on such hands-on circuit control. > > -Bill
Now my answers inside. William Budington: > Does anything like this currently exist? tun2socks? > I'm using whonix from within Qubes. I'm trying to find a way to > remove the tor ports as an attack surface from the whonix-ws while > still maintaining circuit isolation for applications run within > workstations. > Currently, I see that the tor ports are forwarded from > the whonix-gw via rinetd. re rinetd: Only those used by Tor Browser (and torchat). Other open Tor ports on Whonix-Gateway (such as for HexChat) are under the current implementation directly talked to. (Not that it matters much for the sake of this subject: When you upgrade Whonix-Workstation, anon-ws-disable-stacked-tor was migrated to socat.) > Possible solution: a piece of software intended to be used on > whonix-gw which opens one network interface per circuit, It's an interesting idea. So the application talks to a virtual network interface directly rather than directly to a Tor SocksPort? - Then this virtual network interface would eventually talk to a Tor SocksPort? - Okay, if I got that right, the application couldn't try to exploit a bug in Tor's socks implementation. So the tun2socks application would have to be more resistant against exploitation than Tor's socks code? Eventually we use something like this [1] to configure specific applications to specific virtual network interfaces? > and > provisions an arbitrary number of VMs with circuit-isolated, > transparently torified connections without exposing the tor > socks/control ports to them. That way you could run one application > per VM which is on an isolated circuit, but has no access to the tor > ports. Hm. Alternatively it would be possible to configure Whonix-Gateway's firewall to disallow any socksified traffic. If you like to look into that: whonix-gw Tempalte: /etc/whonix_firewall.d/50_user.conf or sys-whonix: /rw/config/whonix_firewall.d/50_user.conf WORKSTATION_ALLOW_SOCKSIFIED=0 (reload Whonix firewall 'sudo whonix_firewall' in sys-whonix or reboot) [Of course also possible to make more fine tuned changes such as disabling only specific SocksPorts...] Disable stream isolation per application or globally, see [2]. I.e. configure the application you want to use to use transparent torification. [Which is the default, unless the application is configured by Whonix default to use a Tor SocksPort. See list. [3].] Multiple Whonix-Workstations using transparent proxying Qubes-Whonix are already easily automatically stream isolated from each other because they have a different client IP addresses and Tor default uses IsolateClientAddr. You'd end up with your application-A in a anon-whonix-one, that is using transparent proxying and your application-B in anon-whonix-two. anon-whonix-one and anon-whonix-two would be stream isolated (IsolateClientAddr). Both stream isolated from each other. No Tor SocksPort usage involved. [Some thing would have to be sorted out such as sdwdate time synchronization but I also have an idea here that I can specify if this is of interest.] It isn't the default implementation because in Qubes we are not so much considering to run one VM per application, but one VM per security domain (e.g., “work,” “personal,” “banking,” etc.) (multiple applications per VM). And we wouldn't want to funnel all traffic from a whole domain into the same Tor circuit. > Obviously this would be a bad solution for the Tor Browser, which > relies on access to the tor ports to do per-tab isolation. (Tor Browser just talks to only a single Tor SocksPort. [And in the next major version 6.5 it talks to a single unix domain socket.]) [Tor Browser by tab isolates by (ab)using socks user auth.] > But I > figure it would be an okay solution for other applications that do > not rely on such hands-on circuit control. Certainly interesting to discover. Best regards, Patrick [1] http://superuser.com/questions/241178/how-to-use-different-network-interfaces-for-different-processes [2] https://www.whonix.org/wiki/Stream_Isolation/Disable_Easy [3] https://www.whonix.org/wiki/Stream_Isolation#List [4] https://www.qubes-os.org/getting-started/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/63e7b581-5225-cdc8-6ba9-7425863171da%40riseup.net. For more options, visit https://groups.google.com/d/optout.
