adrelanos
commented
6 years ago Let's see why VirtualBox ova files handle this better.
- these contain the VM images
- these also contain the VM settings
- the workstation can have a setting like "may connect to another VirtualBox VM only" (internal networking) (so no external networking to clearnet)
- at the same time, easily downloadable VirtualBox VMs with proxying capabilities are rare
- at the same time, VirtualBox has no easy interface to change from networking "Whonix" to "clearnet" or "other proxying capable VirtualBox VM"
- so the two Whonix VMs, gateway and workstation are "tied together"
By Qubes design:
- more flexible, easy to change NetVM (to clearnet, VPN, Whonix)
- more easily available networking VMS (clearnet, VPN, Whonix)
- template packages don't also ship (network) settings files
- (network) settings are up to other components (qubes-core-admin-addon-whonix, salt)
- in conclusion, are "more loosely tied to each other from a technical implementation viewpoint"
Perhaps the Qubes design could be improved? Perhaps some sort of marker / tag "Whonix" would be ingrained (settings file shipped) with the template packages which would enforce at dom0 level that these can only interact with each other, unless the user clicks through some warning?
That wouldn't solve Updates Proxy but maybe it's a start.
nyxnor
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.orgor 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 ifqubes.UpdatesProxy.policyonly included$anyvm $anyvm denyand 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:
tag:whonix-updatevmAnd 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.orgbeing 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 networkwhonix) - 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).
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.