QubesOS
Clear inter-VM global clipboard after a certain amount of time
The problem you're addressing (if any)
A typical use case it to run a password manager in a different VM (like "vault"), then transfer the passwords via the clipboard to the target VM (to paste it there). While the password managers typically erase the clipboard after some time, the Qubes clipboard keeps the data "forever" (while it's running).
Describe the solution you'd like
It would be somewhat safer if the clipboard were (or could) be erased after some time (e.g. in case the user forgot he had copied the password to the clipboard, thinking something else is in the clipboard).
Of course timing out the global clipboard does not mean the local clipboard in the target VM will be erased, too. So there still is some problem that local use of a password manager does not have.
Where is the value to a user, and who might that user be?
The feature may prevent users pasting secrets where they shouldn't be pasted by mistake. So it's basically a security feature.
Describe alternatives you've considered
Copying some dummy data to the clipboard could overwrite the password there if it's not needed any more.
Additional context
Relevant documentation you've consulted
Related, non-duplicate issues
I guess I had a bit of a design tantrum, and did some mockups for this some time ago. :D
It would be somewhat safer if the clipboard were (or could) be erased after some time (e.g. in case the user forgot he had copied the password to the clipboard, thinking something else is in the clipboard).
This issue is relatively easy to solve. The design could be like this:
Upon copy to global Inter-VM clipboard, the Global Clipboard systray widget (qui/clipboard) could look for a special feature of the source VM and/or GUIVM. Something like global-clipboard-timeout=<VALUE>. The VMs timeout feature should override GUIVM setting (if available). A countdown timer would be triggered and truncate /run/qubes/qubes-clipboard.bin and clean-up the relevant files.
All of the fixes could happen in one repository (qubes-desktop-linux-manager).
PR Submitted.
Review priority: low
Additional notes: A menu item is also added to allow users to manually clear the global clipboard at anytime they desire. Or they could set global-clipboard-timeout feature per VM and/or per GUIVM to have it cleared automatically.
Development notes: This PR would most likely conflict with PR for #9296. It would be better if this one could be reviewed before PR for 9296. So that one could be readjusted to accommodate this change. The applet restarts since /run/qubes/qubes-clipboard.bin is unlinked. This is a benign harmless bug. It could be completely solved with the readjusted PR for 9296.
Video demo:
https://github.com/user-attachments/assets/cef15577-c470-4b17-9beb-b3a5bf8eaf4b
There is a change in plans. According to PR discussion:
what if the widget crashes / someone is using a desktop environment that has problems with the widget, but the person relying on global clipboard will not know that the clearing stopped working (because copy-paste itself will work, just the notifications won't...). @marmarek mentioned that maybe this should happen in the gui daemon for that reason.
So the qubes-quid should fork() itself if the clearing feature/config is set. And the forked subprocess should sleep for X seconds. Then if the existing global clipboard is still from that vm and the same one (maybe some other clipboard action happened in the meantime), it should clear it.
Patches to 3 repositories will be required. qubes-gui-daemon, qubes-core-admin-client to pass the relevant options and finally qubes-desktop-linux-manager. Just for notifications.
The GUI Daemon PR for this is done. I will write the PR for qubes-desktop-linux-manager next. The patch for qvm-start-daemon is just one line. But it should wait for PR for #7730 to be finalized.
I also wondered (don't know the internals, however): If the "owner" of the global clipboard data (the VM or app that provided the data) clears its local clipboard, can't the global clipboard be updated (i.e. also cleared) as well? In contrast if the VM or app is no longer the owner of the clipboard data (i.e.: another VM or app has provided clipboard data), then nothing will happen to the contents of the global clipboard when the local clipboard is invalidated or changed. That way a timed-out password in the clipboard would be propagated and thus be made unavailable.
On Fri, Nov 15, 2024 at 04:20:07PM -0800, sjvudp wrote:
If the "owner" of the global clipboard data (the VM or app that provided the data) clears its local clipboard, can't the global clipboard be updated (i.e. also cleared) as well?
This goes against the rule that global clipboard operations need explicit user consent. But also, it will lead to various confusing corner cases - for example, what if another app in the same VM puts something into the clipboard - should the global clipboard be cleared then?
-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab
if another app in the same VM puts something into the clipboard - should the global clipboard be cleared then?
No, because that app is not the "owner" of the data. I'm assuming that the clipboard content has some unique handle, and only the "owner" knows that handle. (In MS-Windows it seems the owner of the clipboard data can be notified if the clipboard changed (, or maybe any interested app is notified; I don't know): If you selected some text in PuTTY, then the text is highlighted, but once the clipboard is changed, PuTTY removed the highlighting, so you know that the text is no longer in the clipboard.
That's just one example of problematic cases, there surely are more. Anyway, the main reason why this is a bad idea is
This goes against the rule that global clipboard operations need explicit user consent.
Source qube should not have control over the global clipboard beyond what user explicitly requested. This includes clearing that content.