disallow setting netvm of whonix-ws to a non whonix-gw

[nyxnor]

The problem you're addressing (if any)

A Whonix Workstation such as anon-whonix can connect to any netvm. It is set by default to the default Whonix Gateway sys-whonix.

Leaks may occur.

The solution you'd like

I wish for the NetVM property for vms with property whonix-ws to only set as its proxy a vm with property whonix-gw.

The value to a user, and who that user might be

Value: ensure there are not clearnet leaks
Target user: All Qubes-Whonix user

Some things I've thought of

The same way templates for disposables can only be a disposable template vm, I wish to only be allowed to set a netvm of a whonix-ws to a whonix-gw.
The properties are already set by default to both whonix vm templates, the vms can have tags anon-vm and anon-gateway.

What is missing is the code for the gui to only show list and the backend to block incorrect netvms.

Some untested scratch:

# if 'whonix-ws' in vm.template.features and 'whonix-gw' not in vm.netvm.features:
if getattr(vm.template.features, 'whonix-ws', True) \
    and getattr(vm.netvm.features, 'whonix-gw', False):
    raise qubes.exc.QubesValueError(
        'netvm ({}) needs to be an VM with feature whonix-gw set to True'
        .format(vm.netvm.name))

[andrewdavidwong]

A Whonix Workstation such as anon-whonix can connect to any netvm. It is set by default to the default Whonix Gateway sys-whonix.

Leaks may occur.

I believe Whonix already has internal safeguards to prevent such leaks from occurring. Is this correct, @adrelanos?

[andrewdavidwong]

What is missing is the code for the gui to only show list and the backend to block incorrect netvms.

Does that mean the GUI should disallow it, but the CLI should permit it? Seems inconsistent.

[nyxnor]

Does that mean the GUI should disallow it, but the CLI should permit it? Seems inconsistent.

No, both should disallow it.

What is missing is the code for the gui to only show list and the backend to block incorrect netvms.

I said this because I presented a scratch code for the cli. Untested and probably insufficient, just a getting started.

[adrelanos]

A Whonix Workstation such as anon-whonix can connect to any netvm. It is set by default to the default Whonix Gateway sys-whonix.
Leaks may occur.

I believe Whonix already has internal safeguards to prevent such leaks from occurring. Is this correct, @adrelanos?

There's an updates-proxy check but setting anon-whonix to sys-firewall... There's not much that can be done from inside the VM. This is a feature required from the virtualizer. From the Whonix integration perspective, Qubes dom0 is "the virtualizer" (even if technically Xen is involved too).

Even if something could be done from within the VM, it would be much better to have the safeguards enforced on the host / virtualizer (Qubes dom0) level.

Unfortunately, even Whonix for VirtualBox is doing better in this regard.

related:
#3994

[nyxnor]

As it is an enhancement and not a bug, I will state some considerations.
The code from first post is a normal template to app qube relationship.
But whonix could be on a disposable or standalone.

For disposables, are disposables templates are based on an app qube, the disposable check is harder because it has to check against the template of the disposable template.

For standalone, the features of the template are cloned to it at creation, so it is easier.

[andrewdavidwong]

How is this issue different from #3994?

[nyxnor]

If you see the edit on this comment #3994 (comment)
I removed because it was unrelated.

Adrelanos explained here
https://forums.whonix.org/t/change-qubes-network-policy-updatesproxy-to-network-disabled-by-default-for-better-leak-proofness/14147/2

So I opened a new ticket, because the previous one is related to the proxy, template networking, this one is just related to the netvm of whonix-ws (appvm, disp, standalone).

[adrelanos]

How is this issue different from #3994?

This ticket is to disallow settings (using GUI and/or CLI) which are insecure and while maybe still hard to implement might be quite a bit easier less controversial.

#3994 is about changing Qubes internal networking default to secure values. The default networking setting would be none on the lowest levels. 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).

[andrewdavidwong]

Duplicate of #8551

[andrewdavidwong]

This appears to be a duplicate of an existing issue (see #8551 (comment)). If so, please comment on the appropriate existing issue instead. If anyone believes this is not really a duplicate, please leave a comment briefly explaining why. We'll be happy to take another look and, if appropriate, reopen this issue. Thank you.