change Qubes network policy, UpdatesProxy to network disabled by default for better leak-proofness

[adrelanos]

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.

[adrelanos]

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.

[adrelanos]

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.