Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
adrelanos opened this issue Sep 27, 2023 · 15 comments
Labels
C: core C: manager/widget C: networking C: Whonix This issue impacts Qubes-Whonix P: major Priority: major. Between "default" and "critical" in severity. privacy This issue pertains to data or information privacy through technological means. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality. ux User experience

Comments

@adrelanos
Copy link
Member

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)

@adrelanos adrelanos added P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists. labels Sep 27, 2023
@andrewdavidwong andrewdavidwong added T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality. C: Whonix This issue impacts Qubes-Whonix and removed T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists. labels Sep 27, 2023
@andrewdavidwong
Copy link
Member

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.

@andrewdavidwong andrewdavidwong changed the title stop users for changing their anon-whonix Net Qube to sys-firewall to avoid IP leaks Stop users for changing their anon-whonix net qube to sys-firewall to avoid IP leaks Sep 27, 2023
@andrewdavidwong andrewdavidwong changed the title Stop users for changing their anon-whonix net qube to sys-firewall to avoid IP leaks Stop users from changing their anon-whonix net qube to sys-firewall to avoid IP leaks Sep 27, 2023
@andrewdavidwong andrewdavidwong added privacy This issue pertains to data or information privacy through technological means. C: core C: manager/widget ux User experience C: networking labels Sep 27, 2023
@adrelanos
Copy link
Member Author

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
Copy link

jamke commented Sep 28, 2023

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
Copy link

h01ger commented Sep 28, 2023 via email

@h01ger
Copy link

h01ger commented Sep 28, 2023 via email

@marmarek
Copy link
Member

@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
Copy link
Member

@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
Copy link

h01ger commented Sep 28, 2023 via email

@SvenSemmler
Copy link

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
Copy link

jamke commented Sep 29, 2023

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
Copy link
Member Author

@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
Copy link

resulin commented Oct 1, 2023

@andrewdavidwong
Copy link
Member

@adrelanos
Copy link
Member Author

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 andrewdavidwong added P: major Priority: major. Between "default" and "critical" in severity. and removed P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. labels Oct 4, 2023
@andrewdavidwong
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: core C: manager/widget C: networking C: Whonix This issue impacts Qubes-Whonix P: major Priority: major. Between "default" and "critical" in severity. privacy This issue pertains to data or information privacy through technological means. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality. ux User experience
Projects
None yet
Development

No branches or pull requests

7 participants