By contributing to this project, you agree to abide by our Code of Conduct.
This project aims to improve journalists' experience using SecureDrop, by moving the journalist workflow to a single computer running multiple virtual machines with Qubes OS. Data is moved as automatically and transparently as possible between otherwise isolated VMs.
We are currently piloting this project with a small number of news organizations; see our blog post for additional information.
SecureDrop's architecture and threat model are proven, but the current approach also has major drawbacks:
Journalists must access a separate, airgapped device to even validate that a submission is relevant. The airgapped workflow is complex and slow, and may reduce the reliance on SecureDrop overall.
The complexity of the setup and the usage procedures create operational security risks. For example, journalists may accidentally boot up the wrong device using the Secure Viewing Station (SVS) USB drive, breaking the airgap, or they may attempt "workarounds" to shortcut the laborious process of checking for submissions.
Applying security updates to the SVS is difficult, which may cause administrators to wait a long time before doing so. While the SVS is airgapped, an insecure SVS still exposes additional vectors of attack, especially since the journalist is by design opening unknown files on the workstation.
Once a document has been decrypted on the SVS, a journalist is more or less on their own right now. Work on the submission and the collaboration with other journalists are "not our department". Yet, security failures are likely during this stage. It's difficult to address this fundamental issue with the current workflow, since the SVS is essentially a dead end as far as SecureDrop is concerned.
The Qubes OS approach addresses this at multiple levels:
By disabling Internet access and mitigating against other exfiltration risks on a per-VM basis, we can combine multiple functions into a single device. Checking SecureDrop submissions is as simple as booting up your workstation, downloading recent submissions, and inspecting them. This has the potential to greatly reduce time and effort spent by SecureDrop journalists, administators and trainers, and to increase day-to-day SecureDrop use.
Qubes OS' security model lets us add specific software features (such as document redaction, or sanitization via Dangerzone) with careful consideration in each case what level of system or network access an application requires. This lets us gradually extend the functionality we can offer to journalists beyond the mere download of submissions.
We can potentially add VMs that enable end-to-end encrypted communication with other SecureDrop journalists, intermediated by the SecureDrop server. This enables us to add software features that, for example, let journalists collaborate in categorizing submissions, assigning work, versioning changes to documents, and so on.
However, the Qubes OS approach is not without downsides. It stands and falls with the security of Qubes OS itself, which in turn may be impacted by Spectre/Meltdown type CPU level vulnerabilities, hypervisor vulnerabilities, and so on. These risks must be compared against the operational security risks of the current architecture, including the work that journalists do after downloading a submission. The Qubes OS website provides a useful comparison of its security model with that of using a separate machine.
We intend to bring the pilot program to a close in 2024, and move forward with general availability of SecureDrop Workstation following final updates based on the pilot participants' feedback and experience. The general availability version will be compatible with Qubes 4.2. Work is ongoing on 4.2 compatibility, and the mainline of this repo will be in flux and not suitable for production deployment until the work is completed and audited.
For now, if you want to preview SecureDrop Workstation's functionality we recommend following the installation instructions at https://workstation.securedrop.org, which will guide you through installing the latest stable version of SecureDrop Workstation on Qubes 4.1.
The current architecture replaces the Journalist Workstation and Secure Viewing Station Tails installations with specially-configured Qubes VMs; these are the VMs the user will primarily interact with. There are a number of other configured VMs which provide ancillary services.
Currently, the following VMs are provisioned:
sd-proxy
is where the SecureDrop proxy resides, which allows the non-networked sd-app
vm to communicate with the Journalist Interface over Tor.sd-app
is a non-networked VM in which the SecureDrop Client runs used to store and explore submissions after they're unarchived and decrypted. Any files opened in this VM are opened in a disposable VM.sd-whonix
is the Tor gateway used to contact the journalist Tor hidden service. It's configured with the auth key for the hidden service. The default Qubes Whonix workstation uses the non-SecureDrop Whonix gateway, and thus won't be able to access the Journalist Interface.sd-gpg
is a Qubes split-gpg AppVM, used to hold submission decryption keys and do the actual submission crypto.sd-viewer
is an AppVM used as the template for the disposable VMs used for processing and opening files.sd-log
is an AppVM used for centralized logging - logs will appear in ~/QubesIncomingLogs
from each AppVM using the centralized logging service.Submissions are processed in the following steps:
sd-gpg
to decrypt the submission using Qubes' split-GPG functionality (decryption is done in a trusted, isolated VM, keeping GPG keys off of the system-wide DispVM).sd-app
Secure Viewing Station VM, where it's placed in a local database.See below for a closer examination of this process, and see docs/images
for screenshots related to the steps above.
This repository contains the material needed to provision the base Qubes system with the VMs and files required to support SecureDrop Workstation.
Provisioning is accomplished by installing an .rpm in dom0 on a fresh installation of QubesOS, configuring instance-specific
secrets and credentials, then running an orchestration command (sdw-admin --apply
) which configures the machine
in the desired state.
This repository contains the following core components:
securedrop_salt
, which contains all files required during the provisioning (orchestration) stage. Qubes uses SaltStack internally for VM provisionining and configuration management (see https://www.qubes-os.org/doc/salt/). The contents of securedrop_salt
are provisioned to end users via the securedrop-workstatoin-dom0-config RPM.files
, which contain scripts and configuration files placed in dom0 before provisioning, such as systemd units, RPC policy files, and Python scripts. The contents of files
are provisioned to end users via the securedrop-workstatoin-dom0-config RPM.launcher
, sdw_updater
, sdw_notify
, sdw_util
), which comprise a wrapper around the Qubes Updater, and which serve to enforce a fully-patched system. The contents of these directories are provisioned to end users via the securedrop-workstation-dom0-config RPM. The updater updates all TemplateVMs relevant to the SecureDrop Workstation prior to use, and the the sdw-notify.py
script reminds the user to update the system if they have not done so recently.This repo also contains the following developer-facing components:
rpm-build
, containing the components required for building the securedrop-workstation-dom0-config
RPM that is ultimately published to our yum repository.scripts
, which are developer-facing linting and build-related scripts.Makefile
is used with the make
command on dom0
to build the Qubes/SecureDrop installation, and also contains some development and testing features.SecureDrop Workstation has a companion repository, SecureDrop Client, that contains component code for all of the packages we ship in individual VMs once they have been provisioned:
sd-app
and will be used to access the SecureDrop server Journalist Interface via the SecureDrop proxy.sd-proxy
to communicate to the SecureDrop server Journalist Interface via sd-whonix
.sd-devices
and is used to manage printing and exporting files.sd-viewer
VMsd-log
, is provisioned to capture logs locally from various parts of the systemsd-whonix
, is provisioned with instance-specific information required to access the authenticated onion service used by journalists.files/config.json.example
is an example config file for the provisioning process. Before use, you should rename a copy config.json
(in the repository's root directory), then edit config.json
to reflect your environment.sd-journalist.sec.example
is an example private key for use in decrypting submissions in test/development environments. This keypair must not be used in a production environment. Use your own armored Submission Private Key file, named as sd-journalist.sec
, to provision SecureDrop Workstation.Installing this project is involved. It requires an up-to-date Qubes 4.2 installation running on a machine with at least 16GB of RAM (32 GB recommended).
The project is currently in a closed beta, and we do not recommend installing it for production purposes independently. See our blog post for more information. If you are participating in our beta program, please consult our end user documentation for detailed setup instructions, and do not hesitate to reach out for assistance.
To install a development version (using test data on the server and a test encryption key to decrypt it), in summary, you will need to:
config.json
and sd-journalist.sec
(Submission Private Key) appropriate for your environment~/securedrop-workstation
in dom0
dom0
, export SECUREDROP_DEV_VM
(name of your dev VM) and SECUREDROP_DEV_DIR
(full path to repo checkout in dev VM) and run make clone
make dev
in dom0
to provision a development environment.This is only a summary; see our developer documentation for detailed instructions.
This section outlines the threat model for the SecureDrop Workstation, and should complement SecureDrop's threat model. This document is always a work in progress, if you have any questions or comments, please open an issue on GitHub or send an email to securedrop@freedom.press.
dom0
as they are available.As the SecureDrop Workstation is not Internet-reachable, an attacker must first obtain code execution on a virtual machine. This can be achieved through a malicious SecureDrop submission, websites visited by a journalist or a vulnerability in the provisioning code and its dependencies. The Virtual Machine in which the adversary obtains code execution will dictate what information is potentially compromised, as well as the attack surface exposed for lateral movement or escalation of privilege.
sd-viewer
) Can AchieveThe Display VM (sd-viewer) is disposable, does not have network access, and is used to display only one submission before being destroyed.
sd-log
).sd-proxy
) Can Achievesd-log
).sd-whonix
) Can Achievesd-app
) can achieveThe App VM is where securedrop-client resides. It does not have network access, and the Qubes split-gpg mechanism permits access to GPG keys from this VM.
sd-log
).sd-gpg
) Can AchieveThe GPG VM does not have network access, and the Qubes split-gpg mechanism restricts access to this VM per the Qubes GPG RPC policy.
sd-log
) Can AchieveThe Log VM does not have network access nor does it contain any other secrets.
dom0
Can Achievedom0
can do all of the above: spawn arbitrary virtual machines, access all data, modify all SecureDrop Workstation provisioning code, as well as introduce mechanisms to establish persistence and exfiltrate data. By design, Qubes' dom0
does not have network access, files cannot be copied to dom0
, and clipboard sharing is disabled.