Clear automatically the clipboard of an AppVM after a delay when using Ctrl-Shift-V

[SkypLabs]

KeePassX clears automatically the sensitive data contained in the clipboard after a specified delay for evident security reasons.

With Qubes OS, KeePassX (or any equivalent software) is supposed to be used inside the vault AppVM. Passwords are copied from the vault AppVM's clipboard into the targeted AppVM's clipboard through the buffer of the global copy feature. As a result, the vault AppVM's clipboard is cleared by KeePassX but the one of the targeted AppVM is not.

It would be nice to introduce a policy to clear automatically, after a specified delay, the clipboard of an AppVM when using Ctrl-Shift-V and when its content comes from the one of a sensitive AppVM such as vault.

[marmarek]

Generally it is a good idea, but there is one technical limitation right now: target VM don't know from where the content was pasted. And clearing the clipboard unconditionally from dom0 may not be a good idea - you might copied something else there already.

[SkypLabs]

I don't really see the problem of clearing the clipboard unconditionally from dom0. It's actually what KeePassX does. In addition, it would be an optional policy so people having configured it are aware of this behaviour.

[marmarek]

Does it clear the clipboard even if you copy something else already?

[SkypLabs]

I just tested and it seems that no. I didn't know that it was so "smart".

[t-m-w]

I just accidentally pasted a password into the URL bar and pressed enter, LOL. Will have to be very careful.
It's too bad this is set as far in the future because it's the sort of problem I haven't had in less "reasonably secure" operating systems.

[andrewdavidwong]

@80tf3262p8:

I just accidentally pasted a password into the URL bar and pressed enter, LOL. Will have to be very careful.
It's too bad this is set as far in the future because it's the sort of problem I haven't had in less "reasonably secure" operating systems.

That's because most of those other operating systems just have a single global clipboard, not an inter-VM clipboard system. Instead of this problem, though, you probably had a much bigger one: Every app could sniff the contents of your clipboard.

To put it another way: In most other OSes, the password in your clipboard was vulnerable all the time. In Qubes, it's only vulnerable when you accidentally paste it somewhere you didn't mean to.

So, sure, it's true that you didn't have this problem before, but that's because this problem is only made possible by a high level of underlying security that you probably didn't have before.

As for the milestone, this could be addressed sooner if we had a solution to the the technical limitation discussed above. Do you have a solution?

[SkypLabs]

In Qubes, it's only vulnerable when you accidentally paste it somewhere you didn't mean to.

Actually, it's not totally correct. The global copy feature is made in a way that only the target AppVM will receive what's contained in the global copy buffer. No other AppVM can access it and its content is cleared once copied into the target AppVM's clipboard. However, this clipboard will never be cleared automatically, allowing any software to read its content. As a result, the security issue described above is not eradicate in Qubes OS, just limited to the related security domain.

As for the milestone, this could be addressed sooner if we had a solution to the the technical limitation discussed above. Do you have a solution?

A short-term solution would be to clear automatically the target AppVM's clipboard from dom0 after a delay.

[andrewdavidwong]

@SkypLabs:

In Qubes, it's only vulnerable when you accidentally paste it somewhere you didn't mean to.

Actually, it's not totally correct. The global copy feature is made in a way that only the target AppVM will receive what's contained in the global copy buffer. No other AppVM can access it and its content is cleared once copied into the target AppVM's clipboard. However, this clipboard will never be cleared automatically, allowing any software to read its content. As a result, the security issue described above is not eradicate in Qubes OS, just limited to the related security domain.

I don't think we actually disagree, but I think you took that statement out of context. The context was a comparison between the single global clipboard in standard OSes and the Qubes inter-VM clipboard system, so "paste" refers to pasting from the inter-VM clipboard. I'm saying that the password is only vulnerable when you accidentally paste it from the inter-VM clipboard into a VM that you didn't mean to. In a standard OS, where there's only one global clipboard that any app can sniff, any password that gets copied to the clipboard is vulnerable. In Qubes, if you copy a password to the inter-VM clipboard, it's safe from all potential receiving VMs unless/until you paste it into one of them. If you paste it into a receiving VM intentionally, then you're trusting the VM to have that password. If you accidentally paste it into a receiving VM, then you may not trust that VM to have that password. Either way, though, the password is safe in your inter-VM clipboard until you perform the paste action, which is a big security gain over the standard model.

Of course, I agree that after the password is pasted from the inter-VM clipboard into the VM's normal clipboard, it's then vulnerable to everything in that VM, including accidentally pasting it again into some unintended place, which is why it would be nice to have the auto-clipboard-clearing feature in VMs.

[SkypLabs]

I don't think we actually disagree, but I think you took that statement out of context. The context was a comparison between the single global clipboard in standard OSes and the Qubes inter-VM clipboard system, so "paste" refers to pasting from the inter-VM clipboard. I'm saying that the password is only vulnerable when you accidentally paste it from the inter-VM clipboard into a VM that you didn't mean to. In a standard OS, where there's only one global clipboard that any app can sniff, any password that gets copied to the clipboard is vulnerable. In Qubes, if you copy a password to the inter-VM clipboard, it's safe from all potential receiving VMs unless/until you paste it into one of them. If you paste it into a receiving VM intentionally, then you're trusting the VM to have that password. If you accidentally paste it into a receiving VM, then you may not trust that VM to have that password. Either way, though, the password is safe in your inter-VM clipboard until you perform the paste action, which is a big security gain over the standard model.

Of course, I agree that after the password is pasted from the inter-VM clipboard into the VM's normal clipboard, it's then vulnerable to everything in that VM, including accidentally pasting it again into some unintended place, which is why it would be nice to have the auto-clipboard-clearing feature in VMs.

I actually misunderstood your first statement. Thank you for the clarification :)

[tasket]

You could take a pragmatic approach: When Ctrl-V is pressed, inform the user that the guest clipboard will be cleared in X seconds, and then clear it at the designated time.

[SkypLabs]

You could take a pragmatic approach: When Ctrl-V is pressed, inform the user that the guest clipboard will be cleared in X seconds, and then clear it at the designated time.

Don't you mean Ctrl-Shift-V? I'm not sure that dom0 is able to detect if Ctrl-V has been pressed inside an AppVM. But yes it's a good idea.

[artemist]

dom0 can determine if Ctrl-V has been pressed in the VM, but can't determine if Ctrl-V means paste. For example, most terminals use some other binding. By adding complexity, however, we could clear it a certain amount of time after the clipboard is read by messing with the X11 stub in the AppVM

[marmarek]

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

Personally, I frequently keep clipboard content for some time, including pasting it multiple time to an application (for example: copy a link from random browsing VM, then paste into a message, but only after writing its initial part), so I wouldn't want it to disappear automatically. At least not in all the VMs.

Similarly, it would be possible to erase secure clipboard after a delay, if it wasn't pasted to any VM.

[SkypLabs]

That's a great news! Thanks for your insight @marmarek.

I will try to find the time to work on an implementation soon.

[ejose19]

@marmarek Maybe using multiple shortcuts for the desired actions? I agree there are are some scenarios where you want to keep the clipboard for a while, but when dealing with password hanging between vault and target-vms one needs extra care (your first solution would be the best for this).

[donob4n]

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

Why don't just clear with a delay after copying? Generally, users copy something with the immediate intention of paste it somewhere. Copy is like a requirement for the act of paste. If they don't do it in a reasonable interval of time it is very likely that they abandoned their objective and after some minutes they probably even forgot that they had something copied.

This would also void mistakes with inter-qube copy/pastes. If the user forgets the special combination, he will have more chances of paste nothing than something wrong.

Maybe the delay could be restarted in both cases, after copying and after pasting, so the user has another interval for pasting it in more places.

What could be a reasonable delay? five minutes?

[qtc-de]

Hi all 👋

I do not want to abuse this issue to make advertisement, but with qubes-keepass we @codewhitesec created a tool that addresses exactly this problem. It is a simple python script that still uses KeePassXC as backend and rofi as frontend. Let me quickly explain the workflow:

When pressing the configured hotkey for qubes-keepass, dom0 determines the currently focused Qube and uses qvm-run to launch qubes-keepass within your vault VM. Within the vault VM, qubes-keepass uses KeePassXCs DBus integration to fetch available credentials and displays them within rofi. After the user selected a credential, qubes-keepass uses a qrexec service to copy the selected credential into the qube that was previously determined by dom0. After 10 seconds, qubes-keepass clears the clipboard of the qube.

This solution has a far better user experience than clearing the clipboard on a regular basis. It also has other security benefits. We implemented functionality that allows you to configure which qubes are allowed for a specific credential. A credential that is configured for the office qube will never appear when another qube is currently focused, eliminating the risk of pasting credentials into the wrong qube. Moreover, you can configure a minimal trust level a qube needs to obtain credentials via qubes-keepass.

We would love to hear your feedback on qubes-keepass and hope that we can help other Qubes users that are looking for a proper clipboard clearing solution 😃

[marmarek]

Automatic clipboard wipe was implemented in QubesOS/qubes-gui-agent-linux#175 (R4.2), and is also documented in https://www.qubes-os.org/doc/how-to-copy-and-paste-text/#automatic-clipboard-wiping - it's an opt-in feature. I think this issue can be closed, or maybe I'm missing something?

[SkypLabs]

I didn't see it got implemented. Thanks!

I don't see any reason to keep this issue open.