qubes-issues
qubes-issues copied to clipboard
QubesOS
Stop users from changing their `anon-whonix` net qube to `sys-firewall` to avoid IP leaks
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
- configure the Net Qube of
anon-whonixto besys-firewall 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: https://github.com/QubesOS/qubes-issues/issues/3994#issuecomment-397229398
I could be wrong, but this definitely sounds like a feature request to me.
Prohibited by QVMM to change a VM with the
anon-vmqvm-tag to use a VM without theanon-gatewayqvm-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.
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-vmqvm-tag to use a VM without theanon-gatewayqvm-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.
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.
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-vmqvm-tag to use a VM without theanon-gatewayqvm-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.
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)
@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.
@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.
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.
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.
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: https://github.com/QubesOS/qubes-issues/issues/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 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!
-
https://github.com/QubesOS/qubes-issues/issues/3561
-
https://github.com/QubesOS/qubes-issues/issues/7614
@adrelanos, is this issue a duplicate of either of these issues? Are they duplicates of each other?
This ticket is a duplicate of https://github.com/QubesOS/qubes-issues/issues/7614 but I would say keep this ticket and close the older ticket since this ticket's issue description is more clear.
https://github.com/QubesOS/qubes-issues/issues/3561 is related (users shooting own feet with wrong Qubes dom0 settings) a non-duplicate.
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
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).
Please re-open.
I remember looking at this and patching my Qubes Manager temporarily and it failed to account for switching NetVM in the basic view. The pop up only shows in the settings tab, meaning this is only half solved
This should be verified and reported before 4.3 is out, I have not checked the code again
Automated announcement from builder-github
The package manager has been pushed to the r4.3 testing repository for the Debian template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing bookworm-testing (or appropriate equivalent for your template version), then use the standard update command:
sudo apt-get update && sudo apt-get dist-upgrade
Changes included in this update
Automated announcement from builder-github
The package manager has been pushed to the r4.3 testing repository for the Debian template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing trixie-testing (or appropriate equivalent for your template version), then use the standard update command:
sudo apt-get update && sudo apt-get dist-upgrade
Changes included in this update
Automated announcement from builder-github
The component manager (including package manager) has been pushed to the r4.3 testing repository for the Fedora template.
To test this update, please install it with the following command:
sudo dnf update --enablerepo=qubes-vm-r4.3-current-testing
Changes included in this update
Automated announcement from builder-github
The component manager (including package manager) has been pushed to the r4.3 testing repository for the Fedora template.
To test this update, please install it with the following command:
sudo dnf update --enablerepo=qubes-vm-r4.3-current-testing
Changes included in this update
Automated announcement from builder-github
The component manager (including package manager) has been pushed to the r4.3 testing repository for the Fedora template.
To test this update, please install it with the following command:
sudo dnf update --enablerepo=qubes-vm-r4.3-current-testing
Changes included in this update
UX nit: Newbies might be thrown off by this. It says, "Continue at your own risk," but there's only one button: "OK." I can imagine a newbie reading this and thinking, "Oh, I didn't realize what I was doing! Never mind! Abort! Cancel!" All they can do is click the "X" in the upper-right corner, and they might believe that this achieves the abort/cancel they want, since they didn't "continue" by pressing "OK." But I have a feeling clicking the "X" and clicking the "OK" button actually do the exact same thing (namely, simply close the dialog box).
They might not realize that, after this dialog box is closed, regardless of which button they pressed, they must now go back and undo whatever setting they just did (which triggered this warning). At least, I'm guessing that's how it works.
The easiest way to "fix" this might just be to remove the last sentence ("Continue at your own risk."), or maybe include some language like, "If you didn't mean to do this, you should set your net qube back to sys-whonix." A better fix might be to include two buttons that do different things, e.g., [Cancel changes][Accept changes].
(Screenshot from @alimirjamali. Cross-posted from the Qubes OS Forum.)
You're right, that make sense, but:
If a user changes the netvm from the VM list view, a confirmation popup is displayed just after the warning so he can revert changes:
From the VM properties view, after the warning box, a user can simply close the window or click the Cancel button to cancel changes. This is exactly the same when setting a network qube to a template.
But if you really think this is not intuitive, no problem, I can add the 2 buttons you mentioned but maybe we should do the same for the warning on templates when setting a netvm to remain consistent?
You're right, that make sense, but:
If a user changes the netvm from the VM list view, a confirmation popup is displayed just after the warning so he can revert changes:
From the VM properties view, after the warning box, a user can simply close the window or click the Cancel button to cancel changes. This is exactly the same when setting a network qube to a template.
Ah, I see. That's good! My only thought, then, is that the user might not know that this second dialog prompt will appear after closing the warning, but that's relatively minor, IMHO. They'll quickly find out. :)
But if you really think this is not intuitive, no problem, I can add the 2 buttons you mentioned but maybe we should do the same for the warning on templates when setting a netvm to remain consistent?
Would probably be a UX improvement but might not be a big enough deal to be worth spending extra time on, given the above.
Well, patching qubes-manager indeed fixes the issue of changing the netvm via it, but not via command-line or choosing a netvm when creating a new qube. This should be done in qubes-core-admin-adddon-whonix in my opinion.
It's intentionally done this way, see https://github.com/QubesOS/qubes-issues/issues/8551#issuecomment-1738838362
It's intentionally done this way, see #8551 (comment)
Generally, I don't think blocking is appropriate (but technically possible). But a warning in a GUI settings may be a good idea.
I was just replying to [qubes-devel] Strategies for avoiding mismatched NetVMs/DispVMs and AppVMs, but I will wait for your input to understand the reasoning better.