Stop users from changing their anon-whonix net qube to sys-firewall to avoid IP leaks

[adrelanos]

Qubes OS release

R4.2

Brief summary

Some users are shooting their own feet by setting the Net Qube of anon-whonix to sys-firewall. See this example.

There should be some protection in place in QVMM or otherwise to prevent this.

Steps to reproduce

1. configure the Net Qube of anon-whonix to be sys-firewall
2. curl.anondist-orig 1.1.1.1

Expected behavior

simplified:
Not possible to change anon-whonix to any VM other than sys-whonix as Net Qube.

formalized:
Prohibited by QVMM to change a VM with the anon-vm qvm-tag to use a VM without the anon-gateway qvm-tag.

(I wouldn't be opposed to this being only a warning that the user can choose to ignore. But that part does not seem important. That part could remain "patches welcome".)

Actual behavior

Functional networking. IP leak.

Additional information

Whonix for VirtualBox does not have the issue of new users being able to reconfigure this. While possible for advanced users, not something as simple as point and click as it can be done with Qubes. Details here: #3994 (comment)

[andrewdavidwong]

I could be wrong, but this definitely sounds like a feature request to me.

Prohibited by QVMM to change a VM with the anon-vm qvm-tag to use a VM without the anon-gateway qvm-tag.

Keep in mind that this won't affect changing it from the command line. I imagine you probably want at least a warning there too.

[adrelanos]

I could be wrong, but this definitely sounds like a feature request to me.

I would say this is a grave usability bug. But ultimately, it doesn't matter much if classified as bug or feature request.

Prohibited by QVMM to change a VM with the anon-vm qvm-tag to use a VM without the anon-gateway qvm-tag.

Keep in mind that this won't affect changing it from the command line. I imagine you probably want at least a warning there too.

That would be nice too.

[jamke]

Does not look like a bug to me. As I understand the out-of-box settings are properly set. So, the only case when something goes wrong is when user manually and explicitly change qube settings (NetVM). Is it so important to prevent it?

I mean it can happen with VPN netvm that user forgets, or other qube, that supposed to use whonix, but user decided to change the netvm. I would consider more important to prevent changing netvm for offline qubes (e.g. vault) based on tag or something, the chance that it happens is much higher than user breaking whonix qube.

Also in case the user does this, without understanding what they are doing, the onion sites will stop opening, and the user will be able to understand that they broke something.

I get it that anon-whonix is supposed to use anon-gateway, and it does be default. So, I would consider only adding a message dialog with a warning sign in the GUI tool qubes-vm-settings with the tag checks. Terminal commands can produce warning to stderr but not an interactive question because it would break scripts and contract.

[h01ger]

On Wed, Sep 27, 2023 at 02:07:21PM -0700, Andrew David Wong wrote: I could be wrong, but this definitely sounds like a feature request to me.

yup.

> Prohibited by QVMM to change a VM with the `anon-vm` qvm-tag to use a VM without the `anon-gateway` qvm-tag. Keep in mind that this won't affect changing it from the command line. I imagine you probably want at least a warning there too.

that, and what about sys-whonix2 or whatever named sys-whonix clones people might use? (or whatever named sys-firewall clones (or not clones) people might use...)

…

-- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The road to fascism is lined with people telling you to stop overreacting.

[h01ger]

On Thu, Sep 28, 2023 at 02:01:03AM -0700, Holger Levsen wrote: that, and what about sys-whonix2 or whatever named sys-whonix clones people might use? (or whatever named sys-firewall clones (or not clones) people might use...)

...and what about differently named anon-whonix qubes?

…

-- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The empty vessel makes the greatest sound. (William Shakespeare)

[marmarek]

@h01ger different names are not an issue here - both anon-whonix and sys-whonix can (and should) be distinguished by tags, that are added automatically to relevant qubes.

[marmarek]

@adrelanos AFAIR Whonix Workstation used to check if it's connected to Whonix Gateway at start, warn if it isn't and maybe even block network, no? Was this feature removed, or do I remember it wrong?

Generally, I don't think blocking is appropriate (but technically possible). But a warning in a GUI settings may be a good idea.

[h01ger]

On Thu, Sep 28, 2023 at 02:48:12AM -0700, Marek Marczykowski-Górecki wrote: @h01ger different names are not an issue here - both anon-whonix and sys-whonix can (and should) be distinguished by tags, that are added automatically to relevant qubes.

ah, nice. thanks.

…

-- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ If nothing saves us from death, may love at least save us from life.

[SvenSemmler]

I would consider more important to prevent changing netvm for offline qubes (e.g. vault) based on tag or something, the chance that it happens is much higher than user breaking whonix qube.

Just as a hint to you (not relevant to this topic): I accomplish this by dedicated templates -- the ones for offline qubes do not have the qubes-core-agent-networking package installed. In that case you can assign netvm's until the cows come home and there won't be a leak.

[jamke]

Just as a hint to you (not relevant to this topic): I accomplish this by dedicated templates -- the ones for offline qubes do not have the qubes-core-agent-networking package installed. In that case you can assign netvm's until the cows come home and there won't be a leak.

Great idea, thank you! It requires user to be advanced enough for managing own templates, but great.

I proposed a different enhancement that can kind of solve this problem too: #8555
With this enhancement implemented the user that manually disconnected some offline qube from netvm will have to make 2 mistakes: set netvm to something and check the checkbox making it explicitly online. It will draw user's attention in case they mixed the qube name, because for usual qube this checkbox will be in default state (online).

[adrelanos]

@adrelanos AFAIR Whonix Workstation used to check if it's connected to Whonix Gateway at start, warn if it isn't and maybe even block network, no? Was this feature removed,

I don't think this ever existed. Would be hard to implement in a clean, stable way.

or do I remember it wrong?

Similar stuff is implemented. (Notify if connected to non-torified UpdatesProxy; block networking if firewall failed to load.)

Generally, I don't think blocking is appropriate (but technically possible). But a warning in a GUI settings may be a good idea.

Yes, that would be great!

[resulin]

• Display a privacy risk warning when attempting to change anon-whonix's default_dispvm value #3561

• disallow setting netvm of whonix-ws to a non whonix-gw #7614

[andrewdavidwong]

• Display a privacy risk warning when attempting to change anon-whonix's default_dispvm value #3561
• disallow setting netvm of whonix-ws to a non whonix-gw #7614

@adrelanos, is this issue a duplicate of either of these issues? Are they duplicates of each other?

[adrelanos]

This ticket is a duplicate of #7614 but I would say keep this ticket and close the older ticket since this ticket's issue description is more clear.

#3561 is related (users shooting own feet with wrong Qubes dom0 settings) a non-duplicate.

[andrewdavidwong]

Related discussion thread on the Whonix Forums:

https://forums.whonix.org/t/re-stop-users-from-changing-their-anon-whonix-net-qube-to-sys-firewall-to-avoid-ip-leaks/17255

[adventureru]

I think it should be stated that Whonix appears broken without sys-whonix as its NetVM. Tor Browser won't work, apt won't work, curl, wget and so and so won't work. I don't agree with locking it down entirely, but in almost all cases changing the NetVM to anything but sys-whonix or none* will result in an IP leak, a "broken" system, and a confused user.

Abstracting away from Whonix is great, but if that results in nothing ever happening, then not so much. Adding a warning is the bare minimum I would expect to protect less technical users.

* Whonix VMs without networking are still useful to work in a generic environment (UTC timezone, etc).