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 -- 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/20251019231557.326b615d%40kf-m2g5.
pgps0T55Hg13g.pgp
Description: OpenPGP digital signature
