Strategies for avoiding mismatched NetVMs/DispVMs and AppVMs

[Aaron Rainbolt]

A few days ago, an issue was filed against
qubes-core-admin-addon-whonix in Qubes R4.2, pointing out that if the
user clones a Whonix-Workstation template into a new template or
standalone, the default DispVM specified for the template or standalone
will be the system-wide default DispVM (usually default-dvm, which is
oftentimes a Fedora 42 system), rather than whonix-workstation-17-dvm
like one would expect. This ultimately risks an anonymity leak, as
software in the workstation can attempt to open a DispVM and run a
command in it that does network access. Depending on how the user has
configured their system, this may or may not require user interaction
to trigger the leak.

The current plan to fix this is to make a bunch of changes to
qubes-core-admin-addon-whonix to make its logic for setting the DispVM
and NetVM for Whonix qubes more robust; currently my plan is to work
with ben-grande on getting his PR merged into R4.3, then backport the
majority of his work to R4.2, hopefully keeping this sort of thing from
happening to anyone (else) in the wild. However, this arguably only
fixes part of the problem; the real problem is that Whonix-Workstation
VMs can have their DispVM or NetVM set to something that doesn't offer
the anonymity and security guarantees that the "correct" VMs would
offer. The DispVM should always be set to something that prevents
anonymity leaks (i.e. a Whonix-Workstation or perhaps an un-networked
qube), while the NetVM should always be set to something that routes
traffic through Tor and offers the appropriate services to the
workstation (in practice this currently means a Whonix-Gateway AppVM is
the only acceptable NetVM, if any NetVM is to be used at all). Even if
there aren't software bugs to get these settings wrong for the user,
the user might just set the settings wrong themselves. This same sort
of issue could theoretically occur with other VMs; perhaps a user has a
work-related AppVM that must only use a NetVM that routes traffic
through their workplace's VPN, and setting the NetVM to anything else
risks leaking sensitive data (maybe it tries to make unencrypted HTTP
connections to company-internal servers and embeds sensitive things
into the URLs it tries to access).

This makes me wonder if it might be a good idea to introduce some
code into qubes-core-admin that would allow restricting what NetVMs and
DispVMs are legal for a particular qube to have. Perhaps a qube could
advertise two features (or have them manually set by the user) that
would specify what VMs could be "legally" used by that VM for DispVMs
and AppVMs. If a VM needed to use a particular "class" of NetVMs or
DispVMs, it could specify one or more VM tags rather than exact names
(though exact names would still be useful for users who wanted to
"lock" a VM to a particular DispVM or NetVM for whatever reason). Then
qubes-core-admin would prohibit setting the NetVM or DispVM to anything
that wasn't allowed by these features, and Qube Manager would only
display "legal" VMs for the relevant fields in its UI. In this way,
almost no matter what bug or inadvisable user action is taken, a
dangerous DispVM or NetVM cannot be set. (Of course, if a user deletes
the relevant features from their AppVM, or if code does likewise, this
would be broken, but there's little that can reasonably be done about
that.)

Does this sound like a decent plan? Are there issues with this that
would make it undesirable? If not, I'll file this as a feature request
and probably work on it in the not-too-distant future.

--
Aaron

[unman]

Sounds like a reasonable plan, although I do think it's incumbent on
users to not make such mistakes.
I dont use Whonix, but the obvious issues I see could be:
1. Ability to have netvm of disposable set to none. (Covered in your
proposal, I think.)
2. Chaining of qubes, where ultimate qube has no netvm, or netvm set to
Whonix, or not. How will you encompass *that*?

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

This is an interesting idea. Generally, making it harder to set
dangerous configuration is a good idea. But also, I don't think should
be completely blocked. For example there may be cases where one wants
to use Whonix Workstation based qube just because they like default
settings there, but don't really care about the anonymity aspect. Or
they want to use some replacement that isn't really Whonix.

A simpler whonix-specific solution was considered before, but since it
was based on more-or-less hardcoded Whonix-ness of specific qubes, it
didn't allowed necessary flexibility (like allowing the user to change
the value anyway). There is also a problem of respecting user choice -
to set proper defaults, but do not override user intentional changes.

An API for listing valid choices for netvm and dispvm via qvm-features
seems like a good idea, as it would prevent unintentionally setting
dangerous value, while still could be overridden by advanced user.
So, it could be for example "allowed-netvm" feature that would be a
space separated list of names, or `@tag:something` values (syntax
inspired on qrexec policy). And similar for "allowed-default-dispvm".
And then, core-admin could could use those via "check_with_template"
function, so it's enough to set it once on whonix-workstation-18
template, not necessarily on every app qube based on it.

And while at maybe also "allowed-template"? To prevent accidental
template change, but still allow for example switching from
whonix-workstation-17 to whonix-workstation-18 (or even some clone of
them). But I'm not sure if that's really a good idea.

As for respecting user choice, this still has similar issue as before,
but moved elsewhere - now qubes-core-admin-addon-whonix could set those
features, but would need to be careful to not override user-configured
value, especially if some future version would need to change the value.
We do have a mechanism for distinguishing built-in defaults from user
changes, but we don't have it for changes made by an addon (or salt)...
Something to consider maybe in the future...

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmj2eNUACgkQ24/THMrX
1ywZxAf9FILapcCgEVGz+EjvPPTz+aLoPVLPfxeCPBRV+bTxYtNLhmpAJmZDruG5
NLnpNgMrMQSlK3cnz0yrJglE1ulC6nrXTWw1+9h+0lp6FX1BfMrG+V+HG2bRU/yW
miIZsX1c5dbvQ74Paux/cZldc2yAHT3SzMRi86XjGG/MDrfkcvK+LPHn4IffZEy+
UPew9roaBlQ5vP0XU9sLiVg2U2LB8skpdun7fj+vujUKY6iMBgDZCFFM7WzZdYHV
lfV9ZPaRVXDTkHxePfsn0iuQaz0n3P0GPdj3rl1+m7J22p19wbDgBHIqup6ZYUU0
xb+g/KEh3rl5rt4KJE4sh2Ri7dyuYA==
=9cgq
-----END PGP SIGNATURE-----

[Aaron Rainbolt]

On Mon, 20 Oct 2025 11:27:45 +0100
unman <un...@thirdeyesecurity.org> wrote:

> Sounds like a reasonable plan, although I do think it's incumbent on
> users to not make such mistakes.
> I dont use Whonix, but the obvious issues I see could be:
> 1. Ability to have netvm of disposable set to none. (Covered in your
> proposal, I think.)

Yes, that should be allowed in any event.

> 2. Chaining of qubes, where ultimate qube has no netvm, or netvm set
> to Whonix, or not. How will you encompass *that*?

That's a good question. In general, it should usually only matter what
NetVM a qube is directly connected to - NetVMs further upstream aren't
much different than routers and ISP hardware between the user and the
websites they access. However, in some situations it might be
reasonable to need a NetVM somewhere in the connection chain, even if
another NetVM can be the directly connected one (for instance perhaps
the user has a firewall qube that only allows access to company
resources - it's enough for that firewall to be anywhere in the chain,
even if the user wants to insert a different NetVM between the firewall
and the AppVM (for instance to run mitmproxy or Wireshark on it). It's
a bit trickier to imagine situations where someone would want to
require both a direct NetVM connection and specify another NetVM as
something that needs to be somewhere in the chain, but I guess it could
happen, and it might be more work to only allow one scenario or the
other than it is to just support both simultaneously.

--
Aaron

[Aaron Rainbolt]

Agreed. We don't have to make it too easy to override things in that
way, but adding a bit of difficulty should help make it more likely that
users really know what they're doing before they do it. Perhaps it
would work to add somewhere in the Qube Manager user interface a place
where the user could configure allowed NetVMs, DispVMs, and templates.
I'm not sure that would fit comfortably in the "Advanced" tab, but I'm
also not sure if it deserves a full tab of its own.

> A simpler whonix-specific solution was considered before, but since it
> was based on more-or-less hardcoded Whonix-ness of specific qubes, it
> didn't allowed necessary flexibility (like allowing the user to change
> the value anyway). There is also a problem of respecting user choice -
> to set proper defaults, but do not override user intentional changes.

ben-grande has recently been working on a patch to make
qubes-core-admin-addon-whonix better in this regard, although currently
it's only designed to respect it if the user sets their NetVM or DispVM
to "None". Otherwise it overrides "inadvisable" decisions, similar to
what the plugin does today. It might be possible to make this better
yet still.

> An API for listing valid choices for netvm and dispvm via qvm-features
> seems like a good idea, as it would prevent unintentionally setting
> dangerous value, while still could be overridden by advanced user.
> So, it could be for example "allowed-netvm" feature that would be a
> space separated list of names, or `@tag:something` values (syntax
> inspired on qrexec policy). And similar for "allowed-default-dispvm".
> And then, core-admin could could use those via "check_with_template"
> function, so it's enough to set it once on whonix-workstation-18
> template, not necessarily on every app qube based on it.
>
> And while at maybe also "allowed-template"? To prevent accidental
> template change, but still allow for example switching from
> whonix-workstation-17 to whonix-workstation-18 (or even some clone of
> them). But I'm not sure if that's really a good idea.

An allowed-template feature seems like a good idea to me. The user
might have things in /rw that are tailored to a specific OS and won't
work on a different OS (i.e. if someone changed template from
Whonix-Workstation 18 to Fedora 42).

> As for respecting user choice, this still has similar issue as before,
> but moved elsewhere - now qubes-core-admin-addon-whonix could set
> those features, but would need to be careful to not override
> user-configured value, especially if some future version would need
> to change the value. We do have a mechanism for distinguishing
> built-in defaults from user changes, but we don't have it for changes
> made by an addon (or salt)... Something to consider maybe in the
> future...

Agreed. But maybe we don't need an explicit mechanism like that, as
long as the plugin only makes its changes once per VM it is intended to
affect. For Salt, I don't have much insight there as I've never had a
need to use Salt yet.

I think this is probably enough for me to file a decent feature request
in qubes-issues and possibly comment further on Ben's
qubes-core-admin-addon-whonix PR. Thanks for the feedback!

--
Aaron

[Gerhard Weck]

I think it's a good idea to prevent users from inadvertently making dangerous changes to their network configuration, possibly creating a loophole they would avoid if they knew what they were doing. Also, `qvm-features` seems to be a good place to define which network configurations should be disallowed or at least avoided.

Thinking about that, another problem came to me. Defining such rules via `qvm-features` will cause error messages to pop up whenever the user tries to do something they flagged as unwanted or forbidden. At that time, the previous setting in `qvm-features` may be long forgotten, or it may even have been created by someone else. Here, it may be helpful if one does not need to get into the CLI to see the settings.

But this problem is not restricted to the situation handled here. So it could be a good idea to provide some GUI interface, perhaps in the Qube Manager, to see and manipulate the `qvm-features` parameters of the qubes. Perhaps the Advanced tab could show a field allowing the selection of individual parameters and setting or deleting them?

What do you think about that? Clearly, this would require some work, but it might also help to set sensible values for the parameters to be defined here, and it might also show suitable warnings if dangerous values are selected.