Consolidate SDW templates wherever possible

[conorsch]

We currently have six (6) TemplateVMs and seven (7) AppVMs as part of the core Workstation components:

[user@dom0 ~]$ qvm-ls --tags sd-workstation | grep TemplateVM | wc -l
6
[user@dom0 ~]$ qvm-ls --tags sd-workstation | grep AppVM  | wc -l
7

For most of the AppVMs, a discrete TemplateVM is not actually required. While there are a few complications with consolidating the templates—multiple SDW packages write to /usr/share/applications/mimeapps.list, for example—the advantages to folding the config into as few templates as possible is significant:

• no more need to parallelize updates (Perform update checks concurrently #403)
• qubes-gui-updater would show pending SDW updates (#238)
• we could trust qvm-features securedrop-workstation-buster updates-available to trigger preflight updates, dramatically reducing Client app start time
• update-checking requires 1-3 checks, rather than 6-8 (including Whonix, Fedora)

Here's a short list of proposed changes required in order to achieve the consolidation described:

• prefer /home/user/.config/mimeapps.list to /usr/share/applications/mimeapps.list,
  so AppVMs based on the same TemplateVM can have different mime-handler settings
• update securedrop-log to infer hostname for localvm (rather than hardcode it)
• use /rw/config/ / qvm-service where required for per-VM services (e.g. sd-log, sd-proxy)

We're currently approaching the beta/pilot phase, so unless the team feels strongly that we must immediately reduce the number of templates (e.g. to reduce updater complexity, see #459), and closely coordinate the requisite packaging changes, let's revisit this as a potential reduction to complexity post-pilot.

Implementation

Completed

• Prepare initial template configuration inventory and implementation proposal (this issue)
• Proposal review by @conorsch (this issue)
• Threat model analysis based on initial research
• Consolidate MIME type configuration in securedrop-workstation-config package (Consolidate MIME type configuration in securedrop-workstation-config package securedrop-builder#188)
• Activate AppVM MIME type configuration via securedrop-workstation-config package (Activate AppVM MIME type configuration via securedrop-workstation-config package #603)
• Spike: Provision large/small template via Salt (working branch) - Create small/large templates #608
• Spike on import-export branch to investigate update strategy

Next up

• Continued threat model documentation based on analysis of small/large template
  • Provide list of packages in each template post-consolidation
• Create new sd-viewer metapackage to provide application dependencies for disp VMs: Create new metapackage to track application dependencies for sd-viewer based dispVMs securedrop-builder#197
• Ensure that split-gpg environment variable (QUBES_GPG_DOMAIN) is only set in sd-app or appropriate dev VM Disable executable scripts in AppVMs other than sd-app securedrop-client#1141
• Ensure that securedrop-client (both main client binary and shell script) cannot be run outside of sd-app or appropriate dev VM Disable executable scripts in AppVMs other than sd-app securedrop-client#1141
• Move /etc/sd-proxy.yaml to private volume for sd-proxy ( [securedrop-proxy] Move sd-proxy.yaml into private volume securedrop-proxy#147)
• Remove mimeapps.list from securedrop-client and securedrop-export packages Removes mimetype associations securedrop-export#65 and Remove mimetype associations from package securedrop-client#1160
• Ship the open-in-dvm.desktop file only once, rather than twice Reorganizes mimetype declarations for template consolidation securedrop-builder#198
• Ensure sd-app mimetypes (open-in-dvm always) stored in /usr/share/applications/mimeapps.list (requires packaging & test updates)
• Finalize, review and merge changes to provisioning and update logic Template consolidation via GUI updater #619
  • Move mimetypes for sd-devices{,-dvm} into private volume
  • Ensure we have test coverage that ensures everything is in the right place
  • Handle sd-proxy MIME types in private volume and phase out do-not-open-here script in sd-proxy Move securedrop-proxy mimetypes to package #615 (comment)
  • Ensure that securedrop-workstation-svs-disp package is no longer installed
  • Provisioning logic changes to support small and large template types
  • Provisioning logic changes to assign AppVMs to new TemplateVMs
  • Provisioning logic changes to delete old TemplateVMs
  • Support automatic update via preflight updater (fallback: sdw-admin run) (cf. Support enforcing state for other VMs #567)
  • Tweak preflight updater to show more plausible percentage
• Publish an RPM on yum-test with changes from Template consolidation via GUI updater #619
• Line up dev/staging environments for QA and promote draft PRs to ready
• Create test plan

Later

• QA and release to production

Edited by @eloquence 2020-09-03 per sprint planning
Edited by @eloquence 2020-09-16 per scoping session
Edited by @eloquence 2020-10-01 per sprint planning

[redshiftzero]

I think this makes sense as a major simplification, faster provisioning time, and for the sped up update time. One thought is instead of having a single securedrop-workstation-buster template or template per-VM instead we could have two kinds of templates that are based on securedrop-workstation-buster:

• Lower security template - We install printer drivers (eventually installing potentially shady drivers will be required for export code as we expand printer support), and potentially an ever expanding suite of programs for opening a broader set of different files. We'd use this for sd-devices and sd-viewer.
• Higher security - we use this for sd-app, sd-log, sd-proxy (which e.g. has the journalist interface URL currently in /etc in the template (we could also change this but regardless I think we'd want to have two types of templates given the considerations in the above bullet)), and sd-gpg. We are more judicious about what we install here since it will be shared between multiple VMs.

[redshiftzero]

We discussed this today (March 11) and decided that:

• after the initial pilot-ready release, we'll proceed with consolidating the templates used for sd-devices, sd-viewer, sd-app, sd-log, sd-proxy, and sd-gpg into two templates: one used by sd-devices and sd-viewer (where we'll install libreoffice and other file opening applications), and one used by sd-app, sd-log, sd-proxy, sd-gpg. This will reduce the number of templates by 4, so should be a significant simplification.
• we'll next investigate our use of the whonix gateway to decide if we should further consolidate sd-whonix and sd-proxy (i.e. installing tor into the shared template used for sd-proxy). To make that determination we'll next:
  1. check in with the threat model to see if we should preserve the split architecture, bearing in mind that we now don't have tor browser installed in sd-proxy so we don't expose the attack surface of the browser,
  2. evaluate the UI widgets used for restarting tor to see which functionality we'd need to support for journalists to use to resolve network issues,
  3. evaluate sdwdate to see if we'd want to use this in the consolidated sd-proxy

Depending on the outcome of these above investigations, we might decide it makes more sense to just keep using our existing sd-whonix, in which case we'll continue to have a separate template for that AppVM.

[emkll]

Number of Templates:

• We have the minimal templates listed as a mitigation (MITIG24 for: Vulnerability introduced via Template Dependency and Malicious (backdoored) VM Template: A reduced package list will reduce the likelihood of compromise, but also potentially the impact (if it affects a sensitive VM such as sd-gpg or sd-client, the impact is higher than for the sd-viewer). In this case, we rely on lack of network and Xen to prevent exfiltration.

• As @redshiftzero notes that some files in /etc/ may be exposed to the disp-vm Consolidate SDW templates wherever possible #471 (comment). If we would want to introduce further config values, this separation is helpful. In some cases, we may need to update the logic to use /rw/ instead.

Having a distinction between trusted and less trusted Templates makes sense to me here, to preserve some mitigations listed above and reducing both likelihood and impact, and allowing further use cases:

• Install software from maybe less trusted repositories or binaries, like drivers or analysis tools
• Allowing end-users to customize their templates for analysis or perhaps communication or other tools
• Minimize the likelohood of Template breakage to the core component of the workstation (the client)

Consolidating sd-proxy and sd-whonix:

I think this makes sense and is supported by some of the previous threat modeling analysis we've done in the past:

• Both THREAT23 and THREAT24 (the compromise of sd-proxy and sd-whonix, respectively) have the same adjusted risk score, which makes sense since both have access to the same amount of information (other than sd-whonix having access to the ATHS secret).

• In both cases, should an attacker have execution in either of these VMs can exfiltrate, via Tor. In the case of the consolidated VMs, they would likely be able to exfiltrate over clearnet as well. I don't think this will add any incremental risk.

• Since we will only be using Tor Hidden Services, there should be no sensitive information transmitted over non-Tor, but we should be mindful of the impact of firewall rules in TemplateVMs vs their associated AppVM(s). For the purposes of ATHS-only communications, I don't see any issues. However, I don't think we should reuse this VM for any browser traffic or as a NetVM more broadly - we should limit via it's use through the Proxy RPC interface.

[eloquence]

We had a further discussion about this today; detailed notes can be found here.

Important agreements:

1. As previously discussed, we'll aim for consolidating towards two templates for now.
2. We'll need to start by inventorying template-specific configurations, whether done via Salt or packages. One approach we want to investigate is consolidating those configurations into packages that are not template-specific, and then activating the AppVM-specific configurations via /rw/config changes (e.g., startup scripts) that are installed via Salt and that will rarely need to be updated.
3. This kind of consolidation can be done before reducing the number of templates.
4. We'll aim to make the entire migration as painless as possible, without requiring a reinstall (but unavoidably requiring a securedrop-admin --apply run).

Unfortunately, we may have to increase the number of templates again if we do want to ship a Signal VM, or offer supported ways to create additional custom VMs that interface with SDW VMs.

We didn't discuss the Whonix deprecation/removal path in detail yet, and will set aside time for that at a future tech mtg.

[eloquence]

For the 7/8-7/22 sprint, we've agreed to start with a research & planning task, consistent with the above:

We'll need to start by inventorying template-specific configurations, whether done via Salt or packages. One approach we want to investigate is consolidating those configurations into packages that are not template-specific, and then activating the AppVM-specific configurations via /rw/config changes (e.g., startup scripts) that are installed via Salt and that will rarely need to be updated.

@rmol has offered to take point on this, with the goal to draft a first implementation plan.

[eloquence]

During the last sprint, @creviera and @emkll have done an initial inventory of template configurations, and will summarize their findings on this issue.

Additionally, during the 8/6-8/20 sprint, we have allocated time towards developing a more detailed implementation plan, which will likely comprise multiple smaller spikes (e.g., "how to manage MIME type handling using a single template").

[eloquence]

@creviera and @emkll have prepared a (currently FPF-internal) doc with a comprehensive inventory and a proposed implementation plan. During the 8/20-9/2 sprint, @conorsch will provide additional review, and we've committed to the deliverables that I've tentatively enumerated as a checklist in the top-level issue description. As with other epics, we will likely want to create dedicated issues for each item.

[conorsch]

Completed review of the template consolidation plan. Overall the proposal to prefer private volume configs is solid. We'll have to be careful to ensure that the mimetypes are handled well (the existing functional tests will be valuable here), and additionally that there's no race if leverage /rw/config rc.local to adjusting the mimetype handlers.

[conorsch]

Regarding the upcoming task

Spike: Provision large/small template via Salt (working branch)

I'm skeptical that'll be very workable without also completing the mime type conversions for the other components, e.g. client, proxy, & export, but with some temporary commits like installing local debs as documented in https://github.com/freedomofpress/securedrop-workstation/wiki/Evaluating-new-deb-package-behavior, we should have plenty to discuss from a WIP branch.

Will ping @zenmonkeykstop tomorrow about whether this task is already underway, otherwise offer to help.

[conorsch]

There's still a bit more rebasing to do before a draft PR goes up on this repo, but will do tomorrow. Local testing, while slow, has been quite positive: we have full template consolidation via the GUI updater, and all portions of the Workstation function as expected after the updater run completes. The test plan will be fairly verbose, and reference a lot of draft PRs visible in the cross-repo references above, but I'm optimistic we won't need to ask admins to run CLI actions to accomplish the consolidation.

[conorsch]

Reopening to track QA period, and ensure we've addressed all the sub-tasks.

[eloquence]

This was completed as part of #624.