On Mon, 20 Oct 2025 20:00:53 +0200 Marek Marczykowski-Górecki <[email protected]> wrote:
> -----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. 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 > - -- > 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/20251020185948.70a0b883%40kf-m2g5.
pgpW8G2CoX4sN.pgp
Description: OpenPGP digital signature
