Consider supporting limited copy/paste

[eloquence]

Currently we prevent copy/paste in all VMs that are part of the project. As we enter real-world usage, we can anticipate an increasing need for copy/paste for a number of situations, e.g.:

• pasting passphrases into the login window from a vault VM
• copying messages from and to the conversation view (e.g., to another secure messaging app)
• copying logs and error messages.

Through RPC policies, we can control this permission with directionality for each VM. We should carefully consider changes to clipboard policy and behavior in the context of our overall threat model.

In particular:

• Is it reasonable to loosen clipboard policies without any additional mitigations for certain VM₁->VM₂ operations?
• Are there mitigations that we can put in place within SecureDrop Workstation VMs that would permit us to further responsibly loosen policies (e.g., can we detect clipboard events in sd-app and purge the clipboard after a paste)?
• Are there mitigations that we should coordinate with upstream (e.g., more fine-grained RPC policies to control purge behavior, a meaningful "ask" policy, clipboard previews, other UX improvements), and which would permit us to further loosen policies?

[eloquence]

Relevant upstream conversation here: QubesOS/qubes-issues#3415 (comment) where @marmarek writes:

Looking at the gui-agent-linux code, it actually knows when it gets pasted into an application, whether it's Ctrl-V or something else. Function process_xevent_selection_req gets called. So, technically it would be possible to implement (at the VM side) any of:

• clear after pasting to an application
• clear with a delay after pasting to the VM
• clear with a delay after pasting to an application

[eloquence]

We discussed this more today as part of our SecureDrop Client Sync.

1) One possible mitigation for password copy/paste mistakes is to wipe the clipboard anytime we transition from the login screen to the client window (online or offline). This is tracked in freedomofpress/securedrop-client#1051

2) Assuming we continue to prevent all copy/paste by default, we may want to provide a supported method to selectively permit it. We discussed using tags, e.g.:

• Any VM tagged send-sd-paste could send pastes to SecureDrop VMs
• Any VM tagged receive-sd-paste could receive pastes from SecureDrop VMs

In this manner, admins could be empowered to use a Vault VM, secure messaging VMs, or other select VMs, without permitting copy/paste across the whole system.

3) To support copying client messages/replies, we need to also make their content selectable in the client; this is tracked in freedomofpress/securedrop-client#1052

If we have consensus on 2 above or some variant thereof, we can use this issue to track it.