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

nyxnor · July 11, 2022, 10:59am

Don’t know if it was this what you wanted, because it seems this issue could be separated in two:

1 - updates proxy network policy
2 - netvm policy for anon-vm

n2:
change Qubes network policy, UpdatesProxy to network disabled by default for better leak-proofness · Issue #3994 · QubesOS/qubes-issues · GitHub

Patrick · July 11, 2022, 5:59pm

github.com/QubesOS/qubes-issues

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

opened 09:02AM - 14 Jun 18 UTC

adrelanos

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.

Tthis ticket isn’t a small bug in qubes-core-admin. It’s about a suggestion to change the global Qubes defaults. The Qubes default should be that all VMs (non-Whonix and Whonix) are non-networked by default. That is to avoid that any VM accidentally gets network access. The user wouldn’t notice any defaults since the default setup scripts would still allow the standard Qubes created VMs to have network by default. However, internally a safer non-networked default would make Qubes-Whonix more leak-proof.

Non-Qubes-Whonix is unaffected.

Whonix VirtualBox versus Other Virtualizers

nyxnor · July 11, 2022, 6:48pm

Sorry but really couldn’t understand that point from reading the issue on github.

An another note, I will redact that comment and put it in another issue.

nyxnor · July 13, 2022, 7:56pm

When None is mentioned, it refer to the value None, as in not networked.
When none is mentioned, it is the normal English word. Or possibly I forgot to capitalize the N when I wanted to refer to non-networked.

qubes netvm policy to be non-networked by default is the summary?

So it would be the equivalent of:

qubes-prefs default_netvm ''

But being set as default for new installations.
And qubes created by default should have netvm set to sys-firewall by default or None?

nyxnor · July 13, 2022, 8:34pm

change Qubes network policy, UpdatesProxy to network disabled by default for better leak-proofness · Issue #3994 · QubesOS/qubes-issues · GitHub

Let’s see…
…
Do you understand it now better?

Is something missing in the middle?

nyxnor · July 13, 2022, 9:39pm

My understanding of disallow setting netvm of whonix-ws to a non whonix-gw · Issue #7614 · QubesOS/qubes-issues · GitHub

Set default_netvm to None by default.
QubesOS default installation qubes should not be connected to ther internet by default, manual configuration to set the netvm for all qubes.
Of course anyone can change the qubes-prefs default_netvm later.

Is that it?

Argument:
Avoid a default netvm, set it to None by default, this avoids qubes getting a network on creation.

Make users explictly set the netvm everytime, unless of course it was preferred otherwise in qubes-prefs.

Patrick · July 15, 2022, 11:15am

Yes. Would be good to use capitalized and code tags.

Yes.

None

Yes. However, should be added:

For some VMs, the such as perhaps the untrusted VM supposed to be used for untrusted web browsing (according to screenshot) would then be set to sys-firewall by higher level tools (preconfiguration tool Qubes salt).

Yes.