TemplateVM "NetVM for DispVM" option easily confused with setting DispVM Template's NetVM

[qbs100]

Qubes OS version (e.g., R3.1):

3.2

Affected TemplateVMs (e.g., fedora-23, if applicable):

fedora-23

---

Expected behavior:

Starting disposable VM should use the NetVM I specified in the "Advanced" tab of of the fedora-23 templateVM.

Actual behavior:

Starting disposable VM uses sys-firewall NetVM ignoring the "advanced" tab setting of the templateVM.

Steps to reproduce the behavior:

1. Right click fedora-23 templateVM in Qubes VM Manager and go to "VM Settings" then "Advanced" tab
2. Under Other, set the option NetVM for DispVM to "VPN" (a proxyVM I made)
3. Hit OK
4. Confirm no disposableVMs are running
5. Open Firefox in disposableVM
6. Right click disp1 in Qubes VM Manager, go to VM Settings, under Basic NetVM I see default (sys-firewall)

General notes:

This issue persists after rebooting.

---

Related issues:

[unman]

@qbs100
I think you misunderstand what's happening here.
What you want to do is to operate on the saved dvm qube, not a Template. Set the netvm on the Basic tab - any disposable VMs based on this will inherit that setting.
The entry on the advanced tab is for disposable VMs which are launched from the dispVM. So if you ran a terminal in a dispVM and then ran qvm-open-in-dvm to open another dispVM, that last one would inherit the entry from the Advanced Tab.

[unman]

@qbs100
I think you misunderstand what's happening here.
What you want to do is to operate on the saved dvm qube, not a Template. Set the netvm on the Basic tab - any disposable VMs based on this will inherit that setting.
The entry on the advanced tab is for disposable VMs which are launched from the dispVM. So if you ran a terminal in a dispVM and then ran qvm-open-in-dvm to open another dispVM, that last one would inherit the entry from the Advanced Tab.

[andrewdavidwong]

@unman is correct, but I can see why @qbs100 is confused. This is a UX issue.

[andrewdavidwong]

@unman is correct, but I can see why @qbs100 is confused. This is a UX issue.

[andrewdavidwong]

@unman, the issue concerns the "NetVM for DispVM" setting on the fedora-23 TemplateVM's Advanced tab, so that's about launching a DispVM from that TemplateVM, not launching a DispVM from another DispVM. In other words:

The entry on the advanced tab is for disposable VMs which are launched from the dispVMTemplateVM. So if you ran a terminal in a dispVM that TemplateVM and then ran qvm-open-in-dvm to open another dispVM, that last one it would inherit the entry from the Advanced Tab.

Agreed?

[andrewdavidwong]

@unman, the issue concerns the "NetVM for DispVM" setting on the fedora-23 TemplateVM's Advanced tab, so that's about launching a DispVM from that TemplateVM, not launching a DispVM from another DispVM. In other words:

The entry on the advanced tab is for disposable VMs which are launched from the dispVMTemplateVM. So if you ran a terminal in a dispVM that TemplateVM and then ran qvm-open-in-dvm to open another dispVM, that last one it would inherit the entry from the Advanced Tab.

Agreed?

[unman]

@andrewdavidwong I don't think you're right.
The issue was that @qbs100 didn't understand that dispVMs are based on the saved dvm file, and take their settings from that. Had she understood that it's not likely that she would have looked to the Advanced tab to change the netvm. (Of course, she might have wondered exactly what the entry on the Advanced tab was for, and looked in vain for an explanation - there really should be a simple guide to the QM.)

[unman]

@andrewdavidwong I don't think you're right.
The issue was that @qbs100 didn't understand that dispVMs are based on the saved dvm file, and take their settings from that. Had she understood that it's not likely that she would have looked to the Advanced tab to change the netvm. (Of course, she might have wondered exactly what the entry on the Advanced tab was for, and looked in vain for an explanation - there really should be a simple guide to the QM.)

[andrewdavidwong]

@unman: My correction of your description of the "NetVM for DispVM" setting on the TemplateVM's Advanced tab still stands. It governs what happens when a DispVM is launched from that TemplateVM, not what happens when a DispVM is launched from another DispVM. If you still think this is wrong, please state exactly why.

The issue was that @qbs100 didn't understand that dispVMs are based on the saved dvm file, and take their settings from that. Had she understood that it's not likely that she would have looked to the Advanced tab to change the netvm.

The (mis)understanding can go in both directions. If someone understands how the "NetVM for DispVM" setting works, they won't mistakenly think that setting it on fedora-23's Advanced tab will affect new DispVMs launched from dom0.

[andrewdavidwong]

@unman: My correction of your description of the "NetVM for DispVM" setting on the TemplateVM's Advanced tab still stands. It governs what happens when a DispVM is launched from that TemplateVM, not what happens when a DispVM is launched from another DispVM. If you still think this is wrong, please state exactly why.

The issue was that @qbs100 didn't understand that dispVMs are based on the saved dvm file, and take their settings from that. Had she understood that it's not likely that she would have looked to the Advanced tab to change the netvm.

The (mis)understanding can go in both directions. If someone understands how the "NetVM for DispVM" setting works, they won't mistakenly think that setting it on fedora-23's Advanced tab will affect new DispVMs launched from dom0.

[unman]

@andrewdavidwong Let's not argue. Yours is correct and can be generalised to any VM, not just a Template. Mine is correct and addressed the actual problem raised:setting the netvm for DispVMs. If you check, I specifically refer to the settings tabs for the saved dvm, because that addresses the issue that op raised.
I don't think there's an issue here.

[unman]

@andrewdavidwong Let's not argue. Yours is correct and can be generalised to any VM, not just a Template. Mine is correct and addressed the actual problem raised:setting the netvm for DispVMs. If you check, I specifically refer to the settings tabs for the saved dvm, because that addresses the issue that op raised.
I don't think there's an issue here.

[andrewdavidwong]

@unman: No problem. My intention was not to argue for argument's sake, but rather to determine whether our apparent difference in perception was due to some deeper issue here, which might have gone otherwise unnoticed. :)

[andrewdavidwong]

@unman: No problem. My intention was not to argue for argument's sake, but rather to determine whether our apparent difference in perception was due to some deeper issue here, which might have gone otherwise unnoticed. :)

[ubestemt]

If I understand correctly this issue is not perceived as urgent. For what its worth, I think it is.

I was just about to report to issues: The first about this setting having no effect. Even if I change it for the DispVM's TempVM and TempVM-dvm and run qvm-create-default-dvm, the NetVM of the DispVM remains unchanged. The second one about the DispVM always inheriting the NetVM of the AppVM it is launched from.

Both are due to my misunderstanding the UX. But I believe the second one is potentially compromising. Say I want to open an e-mail attachment in a DispVM using sys-whonix as its NetVM to prevent my IP address from becoming know to an adversary. But I have saved the file in a AppVM that uses sys-net as its NetVM. If I then run qvm-open-in-dvm in that AppVM, the file is opened in a DispVM that is not torified.

[ubestemt]

If I understand correctly this issue is not perceived as urgent. For what its worth, I think it is.

I was just about to report to issues: The first about this setting having no effect. Even if I change it for the DispVM's TempVM and TempVM-dvm and run qvm-create-default-dvm, the NetVM of the DispVM remains unchanged. The second one about the DispVM always inheriting the NetVM of the AppVM it is launched from.

Both are due to my misunderstanding the UX. But I believe the second one is potentially compromising. Say I want to open an e-mail attachment in a DispVM using sys-whonix as its NetVM to prevent my IP address from becoming know to an adversary. But I have saved the file in a AppVM that uses sys-net as its NetVM. If I then run qvm-open-in-dvm in that AppVM, the file is opened in a DispVM that is not torified.

[unman]

@ubestemt I'm not clear on what you're saying, but then I dont see an issue here. It reads to me as if you still misunderstand the GUI.
A disposableVM does not inherit the netVM of the appVM from which it is called. It uses the value set for "NetVM for DispVM" from the Advanced tab, or dispvm_netvm set from qvm-prefs. If you want the disposableVM to be torified set the appropriate value for that AppVM.

If the problem is that you want a disposableVM to be spawned sometimes torified and sometimes not, then you can either define a keyboard shortcut to change the dispvm_netvm value, and then open the file, or open a Torified disposableVM and then qvm-open-in-vm to the named disposableVM.

I'm sorry if I've misunderstood- perhaps you could make it clearer what you think the issue is, and (since this issue hasn't been touched for some time) what you think a resolution would look like.

[unman]

@ubestemt I'm not clear on what you're saying, but then I dont see an issue here. It reads to me as if you still misunderstand the GUI.
A disposableVM does not inherit the netVM of the appVM from which it is called. It uses the value set for "NetVM for DispVM" from the Advanced tab, or dispvm_netvm set from qvm-prefs. If you want the disposableVM to be torified set the appropriate value for that AppVM.

If the problem is that you want a disposableVM to be spawned sometimes torified and sometimes not, then you can either define a keyboard shortcut to change the dispvm_netvm value, and then open the file, or open a Torified disposableVM and then qvm-open-in-vm to the named disposableVM.

I'm sorry if I've misunderstood- perhaps you could make it clearer what you think the issue is, and (since this issue hasn't been touched for some time) what you think a resolution would look like.

[ubestemt]

@unman The issue is that it is not clear that a VM's "NetVM for DispVM" setting applies (only) to DispVMs spawned from that VM, and the setting is somewhat hidden in the GUI. A user could reasonably expect all DispVMs to use the same NetVM regardless of the VM they are spawned from.

Thus the following could happen: Say I want to open an e-mail attachment in a DispVM that uses sys-whonix as its NetVM to prevent my IP address from becoming know to an adversary. But I have saved the file (the attachment) in a VM that uses sys-net as its NetVM. If I then run qvm-open-in-dvm in that VM, the file is opened in a DispVM that is not torified.

If one understands the GUI, this can easily be avoided, but as it is now it is easy to misunderstand. The resolution would be to make it clear

• that a DispVM inherits the NetVM of the VM it is spawned from by default; and
• that a VM's "NetVM for DispVM" setting only affects DispVMs spawned from that VM.

Also, the "NetVM for DispVM" setting for the DispVM's $TemplateVM and $TemplateVM-dvm has no direct effect on the default NetVM for the DispVM, only for any DispVM spawned directly from those VMs. (A TempVM's setting is of course still inherited by new AppVMs.)

[ubestemt]

@unman The issue is that it is not clear that a VM's "NetVM for DispVM" setting applies (only) to DispVMs spawned from that VM, and the setting is somewhat hidden in the GUI. A user could reasonably expect all DispVMs to use the same NetVM regardless of the VM they are spawned from.

Thus the following could happen: Say I want to open an e-mail attachment in a DispVM that uses sys-whonix as its NetVM to prevent my IP address from becoming know to an adversary. But I have saved the file (the attachment) in a VM that uses sys-net as its NetVM. If I then run qvm-open-in-dvm in that VM, the file is opened in a DispVM that is not torified.

If one understands the GUI, this can easily be avoided, but as it is now it is easy to misunderstand. The resolution would be to make it clear

• that a DispVM inherits the NetVM of the VM it is spawned from by default; and
• that a VM's "NetVM for DispVM" setting only affects DispVMs spawned from that VM.

Also, the "NetVM for DispVM" setting for the DispVM's $TemplateVM and $TemplateVM-dvm has no direct effect on the default NetVM for the DispVM, only for any DispVM spawned directly from those VMs. (A TempVM's setting is of course still inherited by new AppVMs.)

[unman]

Both of the things you refer to are explicitly covered in the docs - https://www.qubes-os.org/doc/dispvm/

By default a Disposable VM will inherit the netVM and firewall settings of the ancestor VM. You can change this behaviour: in the Qubes Manager go to the advanced tab of VM Settings where you can set the default netVM to be used for DisposableVMs created from that VM.

What change can we make to make it clearer?
How about a tooltip that says something like: "Sets NetVM for disposableVMs started from this qube"?

If you want to set the default netVM for disposableVMs you set the netvm for the $TemplateVM-dvm.

[unman]

Both of the things you refer to are explicitly covered in the docs - https://www.qubes-os.org/doc/dispvm/

By default a Disposable VM will inherit the netVM and firewall settings of the ancestor VM. You can change this behaviour: in the Qubes Manager go to the advanced tab of VM Settings where you can set the default netVM to be used for DisposableVMs created from that VM.

What change can we make to make it clearer?
How about a tooltip that says something like: "Sets NetVM for disposableVMs started from this qube"?

If you want to set the default netVM for disposableVMs you set the netvm for the $TemplateVM-dvm.

[ubestemt]

It's been a long time since I last read that document. And I guess we are allowed to expect new users to read the docs. I have tried to improve the relevant paragraphs: QubesOS/qubes-doc#374

To make it clearer in Whonix VM Manager I would propose to add a red * (asterisk) behind the setting as has been done for the "Name & Label" and "Template" settings in the "Basic" tab. Then the footnote would say something like: "Sets NetVM (only) for DispVMs started from this VM. Does not affect DispVMs launched from the Start Menu."

If someone points me to the code for the "Basic" and "Advanced" tabs I will attempt to implement this change -- assuming we reach an agreement on the implementation and the phrasing.

[ubestemt]

It's been a long time since I last read that document. And I guess we are allowed to expect new users to read the docs. I have tried to improve the relevant paragraphs: QubesOS/qubes-doc#374

To make it clearer in Whonix VM Manager I would propose to add a red * (asterisk) behind the setting as has been done for the "Name & Label" and "Template" settings in the "Basic" tab. Then the footnote would say something like: "Sets NetVM (only) for DispVMs started from this VM. Does not affect DispVMs launched from the Start Menu."

If someone points me to the code for the "Basic" and "Advanced" tabs I will attempt to implement this change -- assuming we reach an agreement on the implementation and the phrasing.

[andrewdavidwong]

What change can we make to make it clearer?
How about a tooltip that says something like: "Sets NetVM for disposableVMs started from this qube"?

Another good candidate for #2211.

[andrewdavidwong]

What change can we make to make it clearer?
How about a tooltip that says something like: "Sets NetVM for disposableVMs started from this qube"?

Another good candidate for #2211.

[ubestemt]

I think an explicit warning (e.g. a footnote) would be appropriate because of possible security implications of the option is misunderstood. This warning could be given as a footnote to the NetVM option (in the "Basic" tab; not in the "Advanced" tab as I proposed above). Then a tooltip for the option in the "Advanced" tab would be enough.

[ubestemt]

I think an explicit warning (e.g. a footnote) would be appropriate because of possible security implications of the option is misunderstood. This warning could be given as a footnote to the NetVM option (in the "Basic" tab; not in the "Advanced" tab as I proposed above). Then a tooltip for the option in the "Advanced" tab would be enough.

[marmarta]

In R4, it's made - I hope - much simpler, because there's no longer 'NetVM for DispVM' setting in the Advanced tab. Now the user can just change the DispVM to be used by a given VM. I'm going to add tooltips in R3.2 and close this one.

[marmarta]

In R4, it's made - I hope - much simpler, because there's no longer 'NetVM for DispVM' setting in the Advanced tab. Now the user can just change the DispVM to be used by a given VM. I'm going to add tooltips in R3.2 and close this one.