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

mirrorway · Feb 16, 2018

Qubes OS version:

R4.0rc4

Affected TemplateVMs:

whonix-ws

Steps to reproduce the behavior:

Create Qubes VM
set template := whonix-ws
set networking := sys-whonix

Expected behavior:

VM ready for anonymous use.

Actual behavior:

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.
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:

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).

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 · Feb 17, 2018

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).

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.

I wonder if #3447 makes this a duplicate?

adrelanos · Feb 17, 2018

I wonder if #3447 makes this a duplicate?

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.

mirrorway · 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.

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

awokd · 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?

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.

mirrorway · 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.

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 · 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.

I wonder if #3447 makes this a duplicate?

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

andrewdavidwong · 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.

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?

marmarek · 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?

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?

adrelanos · 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?

(*) 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 · 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

@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:

Build it and install in dom0. If building is a problem, let me know, I can upload to unstable repo.
Restart qubesd service
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 · 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:

Build it and install in dom0. If building is a problem, let me know, I can upload to unstable repo.
Restart qubesd service
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.

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

marmarek · Feb 28, 2018

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

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.

adrelanos · 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.

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.

marmarek · 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.

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 · 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

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

adrelanos · Apr 24, 2018

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

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.

mirrorway · 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.

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

adrelanos · 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

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

marmarek · May 8, 2018

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

Closeable.

adrelanos · Jul 24, 2018

Closeable.

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

andrewdavidwong added bug privacy C: Whonix labels Feb 17, 2018

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

This was referenced Feb 18, 2018

Open

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

Open

DispVMs launched from whonix-ws-based VMs use clearnet by default #3601

andrewdavidwong referenced this issue Feb 23, 2018
Open
phase out manual use of qubes-dom0-update by user / replace it by salt #3447

marmarek closed this in QubesOS/qubes-core-admin-addon-whonix@dbc6c2d Feb 28, 2018

marmarek reopened this Feb 28, 2018

qubesos-bot referenced this issue in QubesOS/updates-status Mar 4, 2018
Closed
mgmt-salt-dom0-virtual-machines v4.0.11 (r4.0) #443

andrewdavidwong modified the milestones: Release 4.0, Release 4.0 updates Mar 31, 2018

adrelanos referenced this issue Apr 26, 2018
Closed
Qubes-Whonix 14 SaltStack state files required #3765

andrewdavidwong assigned marmarek Apr 28, 2018

adrelanos referenced this issue May 5, 2018
Open
qubes-template-whonix-gw should depend on qubes-core-admin-addon-whonix #3881

adrelanos referenced this issue Jun 7, 2018
Closed
qubes-core-agent /etc/qubes/post-install.d mechanism / qvm-features-request broken #3951

marmarek closed this Jul 24, 2018

QubesOS/qubes-issues

Join GitHub today

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

Comments

mirrorway commented Feb 16, 2018 • edited Edited 4 times mirrorway edited Feb 17, 2018 (most recent) mirrorway edited Feb 16, 2018 mirrorway edited Feb 16, 2018 mirrorway edited Feb 16, 2018

Qubes OS version:

Affected TemplateVMs:

Steps to reproduce the behavior:

Expected behavior:

Actual behavior:

General notes:

Related issues:

This comment has been minimized.

andrewdavidwong commented Feb 17, 2018 • edited Edited 1 time andrewdavidwong edited Feb 17, 2018 (most recent)

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

andrewdavidwong added bug privacy C: Whonix labels Feb 17, 2018

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

This comment has been minimized.

adrelanos commented Feb 17, 2018

This comment has been minimized.

mirrorway commented Feb 17, 2018 • edited Edited 3 times mirrorway edited Feb 17, 2018 (most recent) mirrorway edited Feb 17, 2018 mirrorway edited Feb 17, 2018

This comment has been minimized.

awokd commented Feb 17, 2018

This comment has been minimized.

mirrorway commented Feb 17, 2018

This comment has been minimized.

andrewdavidwong commented Feb 18, 2018 • edited Edited 3 times andrewdavidwong edited Feb 18, 2018 (most recent) andrewdavidwong edited Feb 18, 2018 andrewdavidwong edited Feb 18, 2018

This comment has been minimized.

andrewdavidwong commented Feb 18, 2018

This was referenced Feb 18, 2018

This comment has been minimized.

marmarek commented Feb 18, 2018

This comment has been minimized.

adrelanos commented Feb 23, 2018

This comment has been minimized.

marmarek commented Feb 23, 2018

andrewdavidwong referenced this issue Feb 23, 2018

marmarek closed this in QubesOS/qubes-core-admin-addon-whonix@dbc6c2d Feb 28, 2018

marmarek reopened this Feb 28, 2018

This comment has been minimized.

marmarek commented Feb 28, 2018

This comment has been minimized.

marmarek commented Feb 28, 2018

marmarek added a commit to marmarek/qubes-mgmt-salt-dom0-virtual-machines that referenced this issue Mar 4, 2018

qubesos-bot referenced this issue in QubesOS/updates-status Mar 4, 2018

andrewdavidwong modified the milestones: Release 4.0, Release 4.0 updates Mar 31, 2018

This comment has been minimized.

adrelanos commented Apr 2, 2018

This comment has been minimized.

marmarek commented Apr 2, 2018

This comment has been minimized.

adrelanos commented Apr 23, 2018

This comment has been minimized.

adrelanos commented Apr 24, 2018

adrelanos referenced this issue Apr 26, 2018

This comment has been minimized.

mirrorway commented Apr 26, 2018 • edited Edited 3 times mirrorway edited Apr 26, 2018 (most recent) mirrorway edited Apr 26, 2018 mirrorway edited Apr 26, 2018

This comment has been minimized.

adrelanos commented Apr 28, 2018

andrewdavidwong assigned marmarek Apr 28, 2018

adrelanos referenced this issue May 5, 2018

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

This comment has been minimized.

marmarek commented May 8, 2018

adrelanos referenced this issue Jun 7, 2018

This comment has been minimized.

adrelanos commented Jul 24, 2018

marmarek closed this Jul 24, 2018

mirrorway commented Feb 16, 2018 •

edited

Edited 4 times

mirrorway edited Feb 17, 2018 (most recent)

mirrorway edited Feb 16, 2018

mirrorway edited Feb 16, 2018

mirrorway edited Feb 16, 2018

andrewdavidwong commented Feb 17, 2018 •

edited

Edited 1 time

andrewdavidwong edited Feb 17, 2018 (most recent)

mirrorway commented Feb 17, 2018 •

edited

Edited 3 times

mirrorway edited Feb 17, 2018 (most recent)

mirrorway edited Feb 17, 2018

mirrorway edited Feb 17, 2018

andrewdavidwong commented Feb 18, 2018 •

edited

Edited 3 times

andrewdavidwong edited Feb 18, 2018 (most recent)

andrewdavidwong edited Feb 18, 2018

andrewdavidwong edited Feb 18, 2018

marmarek closed this in `QubesOS/qubes-core-admin-addon-whonix@dbc6c2d` Feb 28, 2018

mirrorway commented Apr 26, 2018 •

edited

Edited 3 times

mirrorway edited Apr 26, 2018 (most recent)

mirrorway edited Apr 26, 2018

mirrorway edited Apr 26, 2018