Implement alternative to qvm-open-in-vm

[eloquence]

As we saw with the Fail-Open behavior resolved via freedomofpress/securedrop-builder#221, xdg-open, which we implicitly rely on via qvm-open-in-vm, holds quite a bit of complexity within it: it attempts MIME type->application lookup via multiple files and methods before giving up. This provides a needlessly large surface for an adversary to explore for weaknesses.

For our purposes, a much more narrowly defined allow-list of MIME types and applications would be sufficient and arguably more maintainable. This could be potentially implemented as a custom RPC service with its own policy, which would then let us fully lock down the qubes.OpenInVM policy for sd-workstation VMs.

The scope of this issue is to:

1. propose an alternative to qvm-open-in-vm / qubes.OpenInVM for opening files in disposable VMs or exporting them via sd-devices
2. if there is consensus, implement said proposal.

[eloquence]

The 2020 SecureDrop Workstation audit flagged the risks of our current MIME type definitions being overwritten as a medium severity issue, identified as TOB-SDW-017. From the report:

The salt script used to populate mime type handling for certain VMs, sets the mimeapps.list file in the /home/user/.local/share/applications/mimeapps.list path (Figure 17.1). However, the xdg-open allows for multiple mimeapps.list paths, and it processes them one by one until it finds a handler for a given opened file. The table below lists those paths, according to the Arch Wiki page about XDG Mime Applications. All of this allows an attacker who can create those paths on the system, if they do not exist, to overwrite existing mime type handlers, when an earlier-processed path (than the /home/user/.local/share/applications/mimeapps.list) is used, or, to add new handlers if a later-processed path is used.

Path	Usage
~/.config/mimeapps.list	User overrides
/etc/xdg/mimeapps.list	system-wide overrides
~/.local/share/applications/mimeapps.list	(deprecated) user overrides
/usr/local/share/applications/mimeapps.list /usr/share/applications/mimeapps.list	distribution-provided defaults

Exploit Scenario

Eve uses the TarFile.extractall bug described in Finding 16 to place a malicious~/.config/mimeapps.list file in the sd-devices VM along with a malicious script. Eve then uses another qvm-open-in-vm call to execute arbitrary code in the sd-devices VM.

Recommendations

Short term, fix the issue with multiple mime type handler lists paths being processed by
xdg-open / qvm-open-in-vm, which allows overwriting or adding handlers when the attacker
can create files in certain paths on the system. This may be done either by changing the
appropriate configuration so that only a single mime type handler lists path is used, or, if
there is no such configuration option, by creating all paths and making them read-only.

Figure 17.1: The salt script that installs mime type handler files:

securedrop-workstation/dom0/sd-mime-handling.sls

Line 27 in bcb0ca8

- name: /home/user/.local/share/applications/mimeapps.list

{% if grains['id'] in ["sd-viewer", "sd-app", "sd-devices-dvm"] %}

sd-private-volume-mimeapps-handling:
  file.symlink:
    - name: /home/user/.local/share/applications/mimeapps.list
    - target: /opt/sdw/mimeapps.list.{{ grains['id'] }}
    - user: user
    - group: user
    - require:
      - file: sd-private-volume-mimeapps-config-dir

{% else %}

sd-private-volume-mimeapps-handling:
  file.symlink:
    - name: /home/user/.local/share/applications/mimeapps.list
    - target: /opt/sdw/mimeapps.list.default
    - user: user
    - group: user
    - require:
      - file: sd-private-volume-mimeapps-config-dir

{% endif %}

[rocodes]

backlog pruning:

• mimetype handling is its own issue and this may be an example of needing to address that in a more organized/unified way
• also, having custom qrexec service /arguments would allow us to keep fine-grained control over opening files in other vms