GPG VM (sd-gpg) performs attacker file decryption mitigated
THREATQW7
· Mitigated: Controls in place bring the risk down to an acceptable level.
· Defined in catalog.py:3084
- Risk
- High impact × Low likelihood = 6 medium
- After mitigations
- Low impact × Low likelihood = 2 low
An attacker with control of a VM that has access to the sd-gpg vm may arbitrarily decrypt files by requesting the GPG VM to decrypt.
Threat actors: Nation State / Law Enforcement
Mitigations
No mitigations in place.
Possible further mitigations
- Use hardware token to store submission key MITIGQW8 proposed
- Default Qubes-RPC deny policy MITIGQW15 implemented
- Sanitize/validate GPG payload in sd-svs prior to sending to sd-gpg (https://github.com/freedomofpress/securedrop-client/issues/433) MITIGQW16 proposed
Where it applies
Applies to 1 component in 2 scenarios.
Workstation: reading submissions · sd-gpg
Notes
Existing mitigations: Qubes RPC policy restricts GPG access to the sd-svs VM exclusively. All other requests from other domains are denied by default. Further mitigations: Qubes can always ask for permission to decrypt. Enable passphrase for GPG key, move GPG key on physical token (MITIGQW8), Qubes RPC policy to deny (MITIGQW15), Validate GPG payload (MITIGQW16).
How this threat is matched
Listed for these components. A boundary covers every component inside it.