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.

[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 cleaning 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.

[SkypLabs]

I don't really see the problem of cleaning 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?

[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".

[SkypLabs]

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

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

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

[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?

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

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

[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 :)

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

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

[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

[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