opened 09:02AM - 14 Jun 18 UTC
T: enhancement
C: core
P: major
privacy
C: Whonix
### Qubes OS version:
R4 and above
### Affected component(s):
dom0, Whonix
…### Steps to reproduce the behavior:
Set NetVM of anon-whonix to default (sys-net).
Then use system default networking `curl.anondist-orig https://check.torproject.org` or otherwise to connect to clearnet.
### Expected behavior:
Secure defaults. No clearnet connections possible through small user configuration mistake / oversight.
### Actual behavior:
Insecure defaults. Clearnet leak.
### General notes:
Qubes UpdatesProxy mechanism currently is more likely to produce a leak in future. A leak as in a user expecting to have connections torified while these are over clearnet.
The problem is, that https://github.com/QubesOS/qubes-core-admin/blob/master/qubes-rpc-policy/qubes.UpdatesProxy.policy by default says `$type:TemplateVM $default allow,target=sys-net`. And sys-net traffic isn't torified by default. Therefore, if any of the following goes wrong (salt / tags / qvm-features maybe / qubes-core-admin-addon-whonix), Whonix TemplateVMs might connect through clearnet. Would be better if `qubes.UpdatesProxy.policy` only included `$anyvm $anyvm deny` and then opt-in each and every TemplateVM rather than an opt-out approach.
When the user wants torification, the default non-torification setting needs to be overwritten. This is done by salt:
* https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/blob/master/qvm/template-whonix-gw.sls - which depends on `tag:whonix-updatevm`
* https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/blob/master/qvm/updates-via-whonix.sls
And then there is also https://github.com/QubesOS/qubes-core-admin-addon-whonix.
The user accidentally setting a whonix-ws based AppVM such as anon-whonix to NetVM default (sys-net) results in `curl.anondist-orig https://check.torproject.org` being able to reach it over clearnet. This is a huge disadvantage over the VirtualBox version of Whonix where such mistakes are very very unlikely to happen. (Because the Whonix-Workstation VirtualBox version of Whonix has only an internal network card (in internal network `whonix`) - which cannot accidentally connect to clearnet.)
----
Qubes-Whonix has code to detect wrongly configured Qubes updates proxy settings and refuses to upgrade but that's just a workaround and more complexity (possible including bugs leading to situations where users cannot upgrade or false-positive warnings).
* https://github.com/Whonix/qubes-whonix/blob/master/etc/uwt.d/40_qubes.conf
* https://github.com/Whonix/qubes-whonix/blob/master/usr/lib/qubes-whonix/init/torified-updates-proxy-check
* https://github.com/Whonix/qubes-whonix/blob/master/lib/systemd/system/qubes-whonix-torified-updates-proxy-check.service
There's also `whonixcheck --leak-tests`.
It's not a real fix, not as strong as a technical guarantee as it could be.
----
It's a complex design and interaction. Hard to fully understand (more so the more time passes). Prone for bugs in future or user mistake.
In summary, Qubes default and technical design currently is: network-enabled, clearnet, options to change to network-disabled or torified
For better control of connections the technical design should be: non-networked by default and then opt-in networking by using salt / core-admin-addon's.