-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sun, Oct 19, 2025 at 11:15:57PM -0500, Aaron Rainbolt wrote: > 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.
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----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/qubes-devel/aPZ41fxpcbxoYET-%40mail-itl.
