Assess security implications of multi-user access

[eloquence]

As discussed in #145, we must make a decision whether or not we want to support access by more than one journalist user to a physical workstation in the 0.1.0alpha release or shortly thereafter. To do so, we need to assess the security implications of multi-user access. Since Qubes itself is not a multi-user OS (every system-level user has full dom0 access), we should assume that we're not attempting to protect journalists from each other.

What we're interested in especially is whether there are specific mistakes or accidents that could increase the likelihood of exposing the system to security vulnerabilities in a context where more than one user has access, or that could lead to destruction of data, VMs or configurations.

[emkll]

Here is the analysis of this proposal, as part of Sprint 14. Please feel free to edit this or comment:

I will start off by reiterating that QubesOS does not claim to be a multi-user OS[0] and that anything built on top will either not provide meaningful protections, or will be difficult to implement in a way that is robust and maintainable. We should also consider that SecureDrop will eventually move to per-journalist sources (and per-journalist keys), as enforcing protections for those keys on a single workstation with a multi-user context will be a significant challenge.

Analysis:

Here are the areas in which a multi-user environment would impact the workstation:

System integrity:

• Compromise of any user account or any VM would persist and impact all workstation users in perpetuity. [SYSTEM1]
• Any Workstation Qubes user has root access to dom0, and commands ran in dom0 (or in the Qubes manager) may have significant security implications (e.g. expose VMs to sys-net). There is (to my knowledge) nothing in Qubes or in our provisioning code that guards against this. [SYSTEM2]

Data protection:

• With access to the workstation, any journalist would be in a position to access and export other journalists data and secrets (including GPG keys, passwords, and decrypted submissions). [DATA1]

Auditing:

• Audit logs for all users are stored on the same workstation, and will make it more difficult to investigate/correlate workstation logs with Journalist interface logs, should they be modified or compromised. [AUDIT1]

(labels added by @redshiftzero so I can reference these risks in further comments)

Risk assessment:

Based on our previous analysis of risks to the SecureDrop workstation, areas which would be impacted by the transition to multi-user Journalist Workstation is the “configuration error”, where a journalist alters the workstation configuration (thus affects the integrity of the system) by either error or malice.

In this scenario, the probability increases from Low to Medium (rationale is that the more users use a single system, the probability of error increases, especially where templates, VMs and configurations are long lived). Given that this risk was classified as a High potential impact, and that we have no compensating controls (e.g. workstation provisioning/testing is run at every boot to ensure configuration consistency), the total risk score is the second highest in the entire model, right after a known vulnerability in a TemplateVM that has not been updated.

Furthermore, any compromise of any VMs or templates will persist for all journalists. This would affect the impact, but since it’s already at the highest level, it is not quantifiable (but should still be taken into account as well).

Finally, if per-journalist GPG keys are introduced for SecureDrop in the future, each journalist would potentially have access to all journalists GPG keys on disk.

Possible mitigations/improvements:

Here are possible solutions that would reduce the overall risk of the multi-user environment (obviously this list is not exhaustive, feel free to edit or comment):

System integrity:

• Periodically audit the system configuration to ensure the integrity (through automated means). This would guard against minor/moderate regressions (mostly regressions introduced without malicious intent).
• Provision/bootstrap the workstation and VMs at boot, which would ensure that all VMs are provisioned as they should be, but would also significantly impact usability.

Data protection:

• Encrypt journalist SVS storage (e.g. submissions) and secrets (passwords) with a GPG smartcard.
• Use a GPG smartcard for per-journalist submission keys
• Documentation should be updated to inform of various risks of using shared workstation, and suggest procedures to rotate keys once a journalist is offboarded from SecureDrop (instead of simply taking possession and wiping the SecureDrop workstation, in the case of a single user scenario).

Auditing:

• Consider sending the logs to an external device or server (SecureDrop server?)

Conclusion

From a data protection standpoint, we should be very careful in introducing a multiple users per workstation paradigm: when we introduce per-journalist keys, it will be both challenging from an engineering perspective, and onerous for an admin to meaningfully enforce and maintain per-journalist keys on a single workstation, and will almost certainly require the entire workstation to be reprovisioned from scratch.

Furthermore, maintaining workstation state might introduce significant engineering effort (including but not limited to ensuring that qubes rpc permissions, qvm-prefs are expected for all VMs)

For these reasons, I would lean towards maintaining the scope of the initial releases to one journalist per workstation (nothing would prevent orgs from using multi-user workstations, despite it being discouraged) until per-journalist keys are implemented on SecureDrop to better understand use-cases (user studies?) and implications of multiple users per workstation.

We could also investigate broader hardware compatibility/support : the Qubes HCL[1] contains references to significantly older and cheaper hardware (such as Lenovo T/Xx20 or 30) series laptops.

I am very interested in hearing anyone else’s thoughts on this.

[0] https://www.qubes-os.org/faq/
[1] https://www.qubes-os.org/hcl/

[redshiftzero]

Excellent writeup @emkll, thank you for this. My .2 cents follow

QubesOS does not claim to be a multi-user OS and that anything built on top will either not provide meaningful protections or will be difficult to implement in a way that is robust and maintainable.

Agree 100%.

Some background for the interested observer:

Right now, SecureDrop does not provide compartmentalization between journalists onboarded to the system. There is a global inbox, they share access to replies, and have a shared private key. Only trusted journalists from a single organization are onboarded.

That said, there is desire for SecureDrop to evolve into a system that does have compartmentalization between at least teams and organizations (see: freedomofpress/securedrop#2841), and maybe at an even more granular level (e.g. per-journalist keys as @emkll is mentioning). Each organization or journalist that wants to have meaningful separation between other users of the SecureDrop shares a security domain. In this model, there may be inter-organization or inter-journalist competition. There may be sensitive matters discussed in one organization that should not be available to another. In such a system, sharing a single user account on a single workstation is not appropriate, especially when that single user account has root/dom0 capabilities.

We do need to consider this as we don't want to box ourselves into a development corner where we feel like we need to try to strap on true multi-user functionality to this system.

Short-term

But in the short term, there is a single security domain and if we want to allow users to use the workstation in a kiosk style, we could implement a lightweight mechanism for signing in to the client. These users would share VMs. This would not provide any meaningful separation between journalist's activity and would simply serve to provide useful tracking of who did/who saw what for news organizations. In this situation, we would need to be clear to users of a single Qubes workstation that:

1. Your SecureDrop activity is always visible to other SecureDrop journalists if they wish to view it (no journalist-specific information should be stored on the workstation, so it mitigates the DATA1 risk where journalist-specific info is stored in the workstation).
2. Mistakes can impact other SecureDrop journalists (note: this does not mitigate SYSTEM1 or SYSTEM2).
3. If users want to have private notes or want to customize their Qubes workstation (i.e. to add a Signal AppVM or other) etc., then they must get a separate workstation for their SecureDrop activity. These users are probably using SecureDrop a lot anyway, so this should not be an unreasonable ask.

To partially mitigate AUDIT1, we could log journalist logins/logouts in the client. We'd have to correlate activity across VMs in order to determine which journalists did what.

Medium-term

In the medium-term view where we do have multiple security domains among SecureDrop journalists using a particular instance, we must have users from each security domain use a separate workstation. Indeed, most organizations that want many groups onboarded may want this anyway, e.g. a media conglomerate with multiple local newspapers across the US would need (at least) one workstation per local newsroom regardless, so this also should not be an unreasonable ask.

Thoughts welcome on this

[eloquence]

Thanks much for the thorough analysis! I think framing this in terms of security domains really sharpens our thinking on it and also enables us to speak to news organizations about it using consistent language.

if we want to allow users to use the workstation in a kiosk style, we could implement a lightweight mechanism for signing in to the client.

What do you have in mind? One possible workflow (ultimate UX aside) that I can think of is a tabbed login screen.

__CONNECT TO SERVER__Work offline_

Username: [ Username  ] 
Password: [ Password  ] 
Code:     [ Code      ]

[ Login ]

_Connect to server___WORK OFFLINE__

Username: [ ^ Username ] 

[ Login ]

Excuse the crude ASCII art, the idea here is that if you choose "work offline", you would just have to select one of the users known to the workstation. You wouldn't be able to type an arbitrary name -- this would be a dropdown. Importantly, you wouldn't have to provide a password.

If we do want a minimum level of (weak) security, we could add a PIN as Nina suggested.

[ninavizz]

@ninavizz cc'ing myself fwiw

[eloquence]

I'm closing this issue as the assessment part is technically done, at least for now; we still need to take this information and make a decision, which is tracked in #145.