Decide on multi-user strategy for workstation access

[eloquence]

From what I'm able to determine, we've not explicitly stated our approach to making the SecureDrop Workstation accessible to multiple users within a news organization.

We could, for now, settle on a 1 user 1 workstation restriction for purposes of the 0.1alpha. However, such an approach is likely not workable for smaller news orgs (cost-prohibitive), and carries its own security risks for larger ones. So at minimum I think we need to have a better answer in the long run.

What are the downsides of having multiple users share a single workstation? In such a scenario, how do we want to handle "offline mode" in the client, considering that the client might retain some information on a per-user basis (settings, various counters and flags, etc.)? What other risks would we need to manage?

(Of note, Qubes is not a multi-user OS, so this would likely only be workable if we consider that all users using the workstation have and always will have the same access to files on the filesystem.)

[eloquence]

Recapping the discussion from today's engineering meeting, please add/correct/clarify as needed:

• We've not made a final decision for the purposes of the 0.1alpha and the 0.1beta on how we want to handle multiple users. We should aim to make a decision for the 0.1alpha ASAP.

• There's broad agreement that 1) we need a cost-effective solution for smaller newsrooms, 2) we should minimize post-audit changes that have significant security architecture implications, 3) we will likely implement features down the road that require, at minimum, separate private keys per journalist.

• A per-journalist OS drive (similar to our Tails per-journalist USB drives) may be a reasonable solution, provided performance is acceptable. We need to do performance testing under ideal conditions; (machine with the right specs, fast USB drive); @zenmonkeykstop has volunteered to drive with advice from @emkll, @eloquence will file issue for that.

• Provisioning of hardware tokens (YubiKey or similar) may be another solution, provided private keys are the only information where per-user access segregation must be enforced. There's some concern about the complexity of provisioning (esp. given the need to do so in a secure manner, e.g., via an air-gapped Tails machine), but others have noted that this might only be needed for features that are entirely optional (journalist-to-source comms, journalist-to-journalist comms).

• @emkll will do additional threat model analysis against the model of a single workstation with multiple users, and may offer recommendations regarding storage of encrypted data, use of credentials, etc., if we go forward with that approach. (@eloquence will file issue for that.) We agree that the high level assumption is still that the workstation would be used in a secure environment, and that we primarily want to mitigate against mistakes and accidents, not against malicious journalists who abuse their access. (Even the current SecureDrop architecture would be vulnerable to that.)

• The Qubes team may have useful insights when it comes to the mistakes/accidents part, the per-user USB drive idea, or other implementation options we've not considered. @eloquence will draft note for review by the team.

• Should we decide to support multiple journalists per workstation in the 0.1alpha, at minimum, the database schema of the client will need to be modified to account for this.

• @ninavizz has tentatively expressed confidence that use without an identity (client in offline mode) could simply not expose any user-specific information (e.g., use default preferences, only show system-wide read/unread status).

[eloquence]

Per discussion at the engineering meeting today:

Based on the assessment in #153, we're comfortable moving forward with a "kiosk-style" multi-user setup until such a point that any per-user security domains are introduced. Features that would require per-user security domains include secure journalist-to-journalist or journalist-to-source messaging using per-user private keys, or protected per-user notepads. We're unlikely to introduce those features until after the beta, and they certainly will not be included in the alpha.

I'll still file an issue for evaluating performance of Qubes running as a live USB operating system. Live USB seems like the most realistic option for per-user provisioning in smaller organizations.