Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clear inter-VM global clipboard after a certain amount of time #6641

Open
sjvudp opened this issue May 26, 2021 · 10 comments · May be fixed by QubesOS/qubes-desktop-linux-manager#225 or QubesOS/qubes-gui-daemon#158
Assignees
Labels
C: core P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. pr submitted A pull request has been submitted for this issue. security This issue pertains to the security of Qubes OS. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality. ux User experience

Comments

@sjvudp
Copy link

sjvudp commented May 26, 2021

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

@sjvudp sjvudp added P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality. labels May 26, 2021
@andrewdavidwong andrewdavidwong changed the title Implement clipboard timeout Clear inter-VM global clipboard after a certain amount of time May 26, 2021
@andrewdavidwong
Copy link
Member

Related: #3415

@andrewdavidwong andrewdavidwong added C: core security This issue pertains to the security of Qubes OS. ux User experience labels May 26, 2021
@andrewdavidwong andrewdavidwong added this to the TBD milestone May 26, 2021
@ninavizz
Copy link
Member

ninavizz commented Aug 3, 2021

I guess I had a bit of a design tantrum, and did some mockups for this some time ago. :D

Global Settings—Event Based
Global Settings—Time Based
Menu
Qube Settings—Event Based
Qube Settings—Time Based
Tray

@andrewdavidwong andrewdavidwong removed this from the Release TBD milestone Aug 13, 2023
@alimirjamali
Copy link

alimirjamali commented Oct 19, 2024

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).

alimirjamali added a commit to alimirjamali/qubes-desktop-linux-manager that referenced this issue Oct 26, 2024
Menu item to Global Clipboard widget to allow users to manually clear it
Also `global-clipboard-timeout` feature could be set per VM and/or GUIVM

resolves: QubesOS/qubes-issues#6641
@alimirjamali
Copy link

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:

global_clipboard_timeout.mp4

@andrewdavidwong andrewdavidwong added the pr submitted A pull request has been submitted for this issue. label Oct 26, 2024
@alimirjamali
Copy link

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.

alimirjamali added a commit to alimirjamali/qubes-gui-daemon that referenced this issue Nov 12, 2024
@alimirjamali
Copy link

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.

alimirjamali added a commit to alimirjamali/qubes-gui-daemon that referenced this issue Nov 14, 2024
alimirjamali added a commit to alimirjamali/qubes-gui-daemon that referenced this issue Nov 14, 2024
alimirjamali added a commit to alimirjamali/qubes-gui-daemon that referenced this issue Nov 14, 2024
alimirjamali added a commit to alimirjamali/qubes-gui-daemon that referenced this issue Nov 14, 2024
alimirjamali added a commit to alimirjamali/qubes-gui-daemon that referenced this issue Nov 15, 2024
@sjvudp
Copy link
Author

sjvudp commented Nov 16, 2024

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.

@marmarek
Copy link
Member

marmarek commented Nov 16, 2024 via email

@sjvudp
Copy link
Author

sjvudp commented Nov 16, 2024

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.

@marmarek
Copy link
Member

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.

alimirjamali added a commit to alimirjamali/qubes-gui-daemon that referenced this issue Nov 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: core P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. pr submitted A pull request has been submitted for this issue. security This issue pertains to the security of Qubes OS. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality. ux User experience
Projects
None yet
5 participants