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

whonix-ws-based VMs lack the anon-vm tag #3595

Closed
mirrorway opened this issue Feb 16, 2018 · 20 comments

Comments

@mirrorway
Copy link

commented Feb 16, 2018

Qubes OS version:

R4.0rc4

Affected TemplateVMs:

whonix-ws


Steps to reproduce the behavior:

  1. Create Qubes VM
  2. set template := whonix-ws
  3. set networking := sys-whonix

Expected behavior:

VM ready for anonymous use.

Actual behavior:

  1. if default_dispvm is fedora-26-dvm (this is the default, right?), then you can launch a clearnet browser from that anonymous VM using qvm-open-in-dvm, exposing your IP address.
  2. VM lacks the anon-vm tag, perhaps it should have this like anon-whonix? The tag appears to be used to block time syncing.

General notes:

Maybe whonix-ws should also have anon-vm tag too, and any VM's based on it should inherit it.

Related issues:

@andrewdavidwong

This comment has been minimized.

Copy link
Member

commented Feb 17, 2018

  1. if default_dispvm is fedora-26-dvm (this is the default, right?), then you can launch a clearnet browser from that anonymous VM using qvm-open-in-dvm, exposing your IP address.

This part is a duplicate of #3561 (which also answers your parenthetical question).

  1. VM lacks the anon-vm tag, perhaps it should have this like anon-whonix? The tag appears to be used to block time syncing.

I've updated the title of this issue to be about only this second part.

@andrewdavidwong andrewdavidwong changed the title Pitfalls when creating new whonix-ws-based VMs whonix-ws-based VMs lack the anon-vm tag Feb 17, 2018

@andrewdavidwong andrewdavidwong added this to the Release 4.0 milestone Feb 17, 2018

@adrelanos

This comment has been minimized.

Copy link
Member

commented Feb 17, 2018

I wonder if #3447 makes this a duplicate?

@mirrorway

This comment has been minimized.

Copy link
Author

commented Feb 17, 2018

I'm not sure I understand how #3561 is relevant to the first issue.. #3561 says that default_dispvm of anon-whonix is correctly whonix-ws-dvm regardless of qubes-prefs setting, but I am talking about newly-created whonix-ws-based VMs.

Regardless of what default_dispvm is for either the premade anon-whonix AppVM or the whonix-ws template, new whonix-ws-based VMs get default_dispvm from qubes-prefs, which I think(?) defaults to fedora-26-dvm.

@awokd

This comment has been minimized.

Copy link

commented Feb 17, 2018

What would the fix be, for newly created AppVMs to inherit their default_dispvm from the template instead of the system default?

@mirrorway

This comment has been minimized.

Copy link
Author

commented Feb 17, 2018

According to qubes-prefs template_for_dispvms --default, the default value of the system default_dispvm is actually None, so maybe the dispvm issue is moot or only affects people who deliberately set qubes-prefs default_dispvm.

@andrewdavidwong

This comment has been minimized.

Copy link
Member

commented Feb 18, 2018

I'm not sure I understand how #3561 is relevant to the first issue.. #3561 says that default_dispvm of anon-whonix is correctly whonix-ws-dvm regardless of qubes-prefs setting, but I am talking about newly-created whonix-ws-based VMs.

Regardless of what default_dispvm is for either the premade anon-whonix AppVM or the whonix-ws template, new whonix-ws-based VMs get default_dispvm from qubes-prefs, which I think(?) defaults to fedora-26-dvm.

In #3561, anon-whonix is supposed to refer to all VMs based on whonix-ws, not just the one particular pre-made VM. If I understand you correctly, you're saying that the one whonix-ws-based VM that happens to be pre-made with the name anon-whonix does not exhibit this problem, but all the subsequent use-created ones do. I'll update the other issue to reflect this.

Edit: On second thought, the other issue is now about something distinct enough that it no longer makes sense to combine these two. Filed separately as #3601.

@andrewdavidwong

This comment has been minimized.

Copy link
Member

commented Feb 18, 2018

I wonder if #3447 makes this a duplicate?

Only if we generalize #3447 to include the creation of whonix-ws-based VMs.

@marmarek

This comment has been minimized.

Copy link
Member

commented Feb 18, 2018

It looks like properly creating new Whonix-ws based VM require multiple steps. We can create core-admin extension that would handle all this automatically. Some thing like:
IF:

  • new AppVM is created based on whonix-ws template (or better: a template with "whonix" tag, which would be added by salt, or this extension itself)

THEN:

  • set netvm = sys-whonix (some better idea than hardcoding this name?
  • set default_dispvm = whonix-ws-dvm (some better idea than hardcoding this name?)
  • add anon-vm tag

We can add more to the list above, if needed. And also create similar thing for custom whonix gateways.

This would be a python class, with just one function. I think it should be in separate package. Maybe "qubes-core-admin-addon-whonix" ?

About hardcoding names above: we could use "features" on the template to allow overriding it, for example:

qvm-features whonix-ws appvm-netvm my-sys-whonix
qvm-features whonix-ws appvm-dispvm my-whonix-dvm

Or some alternative logic - like looking for a VM based on whonix-ws with "template_for_dispvms" set to True. And taking the first one such VM.
This is about default value - user is free to adjust the setting later.

After implementing this, the user experience would be(*): create new AppVM based on whonix-ws template, the system will take care about the rest.

(*) almost - the VM creation dialog contains "netvm" setting, which is applied after creating the VM. In theory it is possible to catch this from core-admin extension (something like "intercept the first netvm change"), but it is hacky and I'd like to avoid it.

@adrelanos what do you think?

@adrelanos

This comment has been minimized.

Copy link
Member

commented Feb 23, 2018

I wonder if #3447 makes this a duplicate?
Only if we generalize #3447 to include the creation of whonix-ws-based VMs.

That's the idea for #3447.


Trying to wrap my head around this. It is really complex.

My summary answer is: Generally sounds awesome!


Some details...

We can create core-admin extension that would handle all this automatically.

Sounds great!

Related:
Whonix default VM settings fixes - salt management
#1954

new AppVM is created based on whonix-ws template (or better: a template with "whonix" tag, which would be added by salt, or this extension itself)

whonix tag or better whonix-ws tag?

set netvm = sys-whonix (some better idea than hardcoding this name?

Your question in parentheses is really difficult. For now, perhaps hardcoded to sys-whonix?

Later, perhaps...?

  • If TemplateVM is whonix-ws auto generate the gateway name as one of these options

    • whonix-ws-gateway OR
    • whonix-ws-sys-whonix OR
    • sys-whonix-ws
    • or some better suggestion (all of these are quite geeky, right?)
  • If TemplateVM is whonix-ws-custom auto generate the gateway name as one of these options

    • whonix-ws-custom-gateway OR etc.

set default_dispvm = whonix-ws-dvm (some better idea than hardcoding this name?)

Similar to above.

  • whonix-ws -> whonix-ws-dvm
  • whonix-ws-custom -> whonix-ws-custom-dvm

This would be a python class, with just one function. I think it should be in separate package. Maybe "qubes-core-admin-addon-whonix" ?

Alright with me.

After implementing this, the user experience would be(*): create new AppVM based on whonix-ws template, the system will take care about the rest.

That sounds ideal.

(*) almost - the VM creation dialog contains "netvm" setting, which is applied after creating the VM. In theory it is possible to catch this from core-admin extension (something like "intercept the first netvm change"), but it is hacky and I'd like to avoid it.

No good solution for that through qvm-features?

@marmarek

This comment has been minimized.

Copy link
Member

commented Feb 23, 2018

(*) almost - the VM creation dialog contains "netvm" setting, which is applied after creating the VM. In theory it is possible to catch this from core-admin extension (something like "intercept the first netvm change"), but it is hacky and I'd like to avoid it.

No good solution for that through qvm-features?

Besides technical issue, there is also UX issue - the setting from that dialog is going to be ignored, overridden or such. One idea is to apply netvm setting from that dialog only if was explicitly changed to something else than default. But then still - it will be listed as "default (sys-firewall)", but in reality created VM will have "sys-whonix" netvm. The problem is that the dialog have no means to know that before actually creating the VM (other than duplicating the logic from the extension we're talking about here).

cc @marmarta

@marmarek

This comment has been minimized.

Copy link
Member

commented Feb 28, 2018

@adrelanos see here: https://github.com/QubesOS/qubes-core-admin-addon-whonix

README is not long, but I think it explains what it does. To test it, you need:

  1. Build it and install in dom0. If building is a problem, let me know, I can upload to unstable repo.
  2. Restart qubesd service
  3. Set whonix-ws feature on template: qvm-features whonix-ws whonix-ws 1

VMs created with qvm-create should have all the things discussed here set, VMs created with GUI - all except netvm, as explained above.
We can add more stuff there if you want. I think now it should be better visible what are the possibilities.

@marmarek

This comment has been minimized.

Copy link
Member

commented Feb 28, 2018

One doubt: the name have "addon", but internally "ext"/"extension" terms are used. Not sure if that might be confusing?

marmarek added a commit to marmarek/qubes-mgmt-salt-dom0-virtual-machines that referenced this issue Mar 4, 2018
add whonix-{ws,gw} feature to whonix-{ws,gw} templates
This is preparation for core-admin-addon-whonix. Later the extension
will be able to add the feature itself, but lets do it early, for people
installing the extension later.

QubesOS/qubes-issues#3595
@adrelanos

This comment has been minimized.

Copy link
Member

commented Apr 2, 2018

One doubt: the name have "addon", but internally "ext"/"extension" terms are used. Not sure if that might be confusing?

I would say rename internally to addon as well, then it's fully consistent.

Build it and install in dom0. If building is a problem, let me know, I can upload to unstable repo.

Yes, please do.

@marmarek

This comment has been minimized.

Copy link
Member

commented Apr 2, 2018

I would say rename internally to addon as well, then it's fully consistent.

For this it is too late.

Build it and install in dom0. If building is a problem, let me know, I can upload to unstable repo.

Done. For now, named qubes-core-admin-addon-whonix (version 0.1-1.5). But we can rename it to qubes-core-admin-extension-whonix if you like.

@adrelanos

This comment has been minimized.

Copy link
Member

commented Apr 23, 2018

Some testing done. Could you join the discussion please?

https://forums.whonix.org/t/qubes-core-admin-addon-whonix-for-qubes-r4-testers-wanted

@adrelanos

This comment has been minimized.

Copy link
Member

commented Apr 24, 2018

It's been reported that the anon-vm tag is missing.

@mirrorway

This comment has been minimized.

Copy link
Author

commented Apr 26, 2018

After doing qvm-features whonix-ws-14 whonix-ws 1, new VMs based on whonix-ws-14 do get the anon-vm tag. The testers in the linked thread probably did not know they needed to set the feature in the template.

@adrelanos

This comment has been minimized.

Copy link
Member

commented Apr 28, 2018

Nice! So since it seems to work and did not break anything in bad ways...

So let's migrate this package to Qubes stable? @marmarek

marmarek added a commit to marmarek/qubes-builder that referenced this issue May 8, 2018
marmarek added a commit to marmarek/qubes-builder that referenced this issue May 8, 2018
@marmarek

This comment has been minimized.

Copy link
Member

commented May 8, 2018

Uploaded to current-testing (this is the next step after unstable).

@adrelanos

This comment has been minimized.

Copy link
Member

commented Jul 24, 2018

Closeable.

@marmarek marmarek closed this Jul 24, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.