Make the warning more prominent when a qube has a more restrictive net qube setting than its default disposable template

[andrewdavidwong]

How to file a helpful issue

The problem you're addressing (if any)

Currently, when one opens the settings for a network-connected qube, there may be a yellow triangle with an exclamation point, depending on its settings. Hovering over it provides the following message:

Caution: The default disposable template (see the Advanced tab) has a different net qube than this qube. This configuration may result in unexpected network access. For example, you may have set this qube's net qube to "none" in order to prevent any data from being transmitted out. However, if the default disposable template's net qube is set to "sys-firewall," then a disposable started from this qube may be able to transmit data out, contrary to your intention. You may wish to set the default disposable template for this qube to one with equally restrictive networking settings.

(This was originally implemented as part of the resolution for QSB-47.)

Some users have complained that this warning is too easy to miss. In particular:

• It's not obvious to some users that they're supposed to hover over the yellow triangle exclamation icon in order to learn more.
• One must open the qube's Settings GUI in order to see the icon in the first place. If one creates a new qube without opening its settings or does things via the CLI, one will not see the icon.

The solution you'd like

Make the warning harder to miss. How best to do this is a UX decision, but here are some ideas that users have offered for consideration:

• Show a warning in the GUI when the user first creates a qube. This way, the user will see the warning even if the user doesn't select the "launch settings after creation" option.
• Show a warning when using the CLI. This way, users who use the CLI instead the GUI will also get the warning.

The value to a user, and who that user might be

All users who would benefit from seeing the warning are less likely to miss it.

Related issues and discussions

• https://forum.qubes-os.org/t/are-qubes-really-isolated-security-questions/18497/16
• UX problem with warning icon next to "Networking" field #5115
• DispVMs based on DVM template with default value of default_dispvm always have the DVM template itself as default_dispvm #8680

[emanruse]

Thank you for opening this issue.

I would like to add, if I may, what was commented in the forum thread:

The currently existing mitigation (the UI warning icon, as per QSB-47) is also easy to circumvent. Example scenario (a chain of qubes):

AAA-dvm: template=fedora-xfce, netvm=none, default_dispvm=fedora-xfce-dvm
BBB-dvm: template=fedora-xfce, netvm=none, default_dispvm=AAA-dvm, *no warning
CCC: template=fedora-xfce, netvm=none, default_dispvm=BBB-dvm, *no warning

And in CCC:

[user@CCC ~]$ ping 1.1.1.1
ping: connect: Network is unreachable
[user@CCC ~]$ qvm-run-vm --dispvm 'qvm-run-vm --dispvm "qvm-run-vm --dispvm ping 1.1.1.1"'
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=53 time=20.0 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=53 time=18.7 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=53 time=27.8 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=53 time=20.0 ms
[...]

Meanwhile, regardless of the default_dispvm, in the settings UI of the qube (Firewall rules), one reads the red text "This qube has no net qube. It will not be have any access anyway." which is misleading in this case.

I would also add to "The solution you would like":

• Have a default (upon Qubes OS installation) safe setup:

Option 1: global default_dispvm=none and netvm=none
Option 2: global default_dispvm set to a DVM with netvm=none`

Any/Each of the two would also need a proper UI warning (and by UI I mean not only GUI but possibly also CLI message, displayed e.g. when opening a terminal session). This needs to be documented too (e.g. linked on the installation documentation), informing the user that one must explicitly change the netvm and/or the default_dispvm in order to have network connectivity in disposables.

• Have detection of chains like in the example from above + relevant warnings.

• Synchronize the currently existing warning in Firewall rules with all that.