Discuss update (and/or removal) strategy for non-sys VMs on SDW

[rocodes]

This is a discussion issue for how we should handle the "gray area" of VMs and templates that are or have been used by SDW, but are not exclusively used by SDW, which broadly means answering some philosophical questions:

• Do we update default AppVMs (work, vault, etc) to the newest supported Fedora template, even though they might be in use by users for other purposes?
  • If we decide we don't want to update VMs that users may be using for other purposes, do we change our initial bootstrap instructions (eg: use DispVMs, or try to set up VMs that are dedicated to SDW so can update them at our own discretion)?
• Do we attempt to remove stale templates (or at least their DVM versions) to discourage unsafe use of EOL templates, even though they might be in use by users?
  • (Tangentially-related) Do we uninstall default AppVMs like "personal" and "untrusted" that don't fit our usage model and that are confusing to users [see below]?

Details

Issue 1: update strategy for default templates

SecureDrop Workstation makes use of a few non-sys VMs at different points during the installation:

• work VM, to download the repo metadata and pubkey (ref)
• vault VM, for credential management and for an offline environment to plug in SVS during provisioning (ref)

These VMs are not covered by our Salt state updates to sys- VM templates, meaning that they aren't migrated to the newest supported Fedora template. We should probably change that.

Issue 2: cleanup strategy for stale templates

Longer-term users of SDW have several crufty Fedora templates accumulating, and along with those, menu entries for Fedora-3X-DVM. Those appear right at the top of the Qubes application menu, and can encourage unsafe behaviour (eg launching a DVM browser with an EOL base template).

On the one hand, it would be nice to clean those up (at least the EOL DVM menu entries), and fairly safe to opportunistically remove. On the other hand, it could surprise users if we start deleting their VMs.

Issue 2b: cleanup strategy for unused default VMs

If following default Qubes install instructions and our installation instructions, users will have the default vms (vault, work, personal, untrusted) installed on their machines. We don't use untrusted and personal, and they are confusing according to at least one pilot participant, and could encourage unsafe behaviour. We've also had pilot feedback that the number of items in the Qubes Application Menu is overwhelming.

[zenmonkeykstop]

some thoughts:
If we do take the position that the SDW is a dedicated workstation, and not supposed to be run on a Qubes system in general use, it changes potential approaches somewhat, in that we could be more assertive in terms of which VMs we keep and nuke, and how we apply template updates.

I wonder if for issue 2 it would be worth seeing if there's any upstream interest in having general functionality to identify stale or rarely-used templates and nuke them. docker system prune but for qubes, if you will.

For 2b, I wonder if we could take a leaf from the Tails workstations and configure our own menus.

For all of these points, I'd be inclined to say they should be considered for the Qubes 4.2 version of SDW (1..) only rather than 4.1 (0..), I know they're in the 0.9.0 milestone but it would be way easier to enforce these changes on a fresh install post-pilot.

[deeplow]

There is another middle-ground solution (not my idea) where instead of updating ir removing entirely, there could be some info+nudging about outdated templates and pointers on how to keep these updater.

Also, the following may be relevant here: QubesOS/qubes-issues#8605. It's basically a (WIP) script for simplifying template upgrades for end-users.

[rocodes]

Thanks @deeplow :)

For now I think we want to avoid in-place template upgrades, partly so that we can reason more easily about the system state and feel more confident about the users' environments. (Thinking of for example the upstream bug you filed a while back where in-place debian template upgrades were still configured against the 4.0 template repo, and other edge cases that might be hard to catch).

For advanced users (who have installed additional packages in their templates for use in non-SD context, and so would benefit more from an in-place upgrade) I think we can refer them to upstream docs for now. Users who are just using Qubes for SDW shouldn't have any additional packages installed, and so should be able to get by with our migration (downloads the fresh templates applies them to SD) plus some kind of nudge to switch over their other VMs or follow other procedures if they have made customizations.

This does bring up a good question of what to do if users have customized the fedora base template. We don't really want them to do that; it would be better if they cloned it and applied customizations to their cloned template, as we still use the fedora system template (sys-firewall, sd-fedora-3X-dvm for sys-usb). We may decide we want to clone the base fedora template right after it's been downloaded, to ensure that sys-firewall is running on an unmodified upstream template. (For debian we currently ship our own template but we will move to cloning the system debian template and modifying that to suit our needs, add fpf apt repos and grsec kernel, etc).

[deeplow]

💯 I should have clarified when I linked to the template upgrade scripts that my intention was to at most mention the existence of these to users in the docs and not necessarily trigger user template upgrades, because "here be dragons"! 🐉

[kennethrrosen]

For advanced users (who have installed additional packages in their templates for use in non-SD context, and so would benefit more from an in-place upgrade) I think we can refer them to upstream docs for now.

for clarity, this is not recommended, iirc. or are admins now permitted to host their SDW on workstations used for other purposes?

as to the original premise of the thread, a simple salt execution within the already-present updater script could check for those VMs and remove if present.