"Copy Dom0 clipboard" option does not allow pasting text into domUs

[andrewdavidwong]

Qubes OS version:

R3.2

Affected component(s):

Qubes Manager, inter-VM clipboard

---

Steps to reproduce the behavior:

1. Copy some text into the clipboard in dom0.
2. Right-click the Qubes Manager icon in the system tray.
3. Click "Copy Dom0 clipboard".
4. Receive a notification that some text has been copied into the inter-VM clipboard.
5. Press Ctrl + Shift + V into an AppVM.
6. Nothing happens.

Expected behavior:

Pressing Ctrl + Shift + V into an AppVM in step 5 should paste the text from the inter-VM clipboard into that VM's clipboard.

Actual behavior:

Pressing Ctrl + Shift + V into an AppVM in step 5 appears to do nothing. (It works when I copy the text from another AppVM, but not from dom0.)

---

Related issues:

#3571

[andrewdavidwong]

Oh, it was because I had commented out the dom0 line in my qubes.ClipboardPaste RPC policy file. Once I changed it to "allow," pasting worked as expected. I recommend:

1. Providing a notification that the action was denied (if it was denied).
2. Setting a default policy in case nothing about copying from dom0 is specified in qubes.ClipboardPaste (if such a default does not already exist). If the default is to deny, then just the first point should be enough.

[andrewdavidwong]

Oh, it was because I had commented out the dom0 line in my qubes.ClipboardPaste RPC policy file. Once I changed it to "allow," pasting worked as expected. I recommend:

1. Providing a notification that the action was denied (if it was denied).
2. Setting a default policy in case nothing about copying from dom0 is specified in qubes.ClipboardPaste (if such a default does not already exist). If the default is to deny, then just the first point should be enough.

[marmarek]

Setting a default policy in case nothing about copying from dom0 is specified in qubes.ClipboardPaste (if such a default does not already exist). If the default is to deny, then just the first point should be enough.

Default policy file already have it: https://github.com/QubesOS/qubes-gui-daemon/blob/master/gui-daemon/qubes.ClipboardPaste.policy

Note the comment about "ask"/"allow" there. For dom0 as a source it doesn't matter in practice, but for other domains it does.

Providing a notification that the action was denied (if it was denied).

You mean specifically for clipboard paste, or for any qrexec service in general?
If the latter, IMO there should be also an option for silent deny - for example I don't want a notification about denied qubes.InputKeyboard every time I plug in my yubikey...

[marmarek]

Setting a default policy in case nothing about copying from dom0 is specified in qubes.ClipboardPaste (if such a default does not already exist). If the default is to deny, then just the first point should be enough.

Default policy file already have it: https://github.com/QubesOS/qubes-gui-daemon/blob/master/gui-daemon/qubes.ClipboardPaste.policy

Note the comment about "ask"/"allow" there. For dom0 as a source it doesn't matter in practice, but for other domains it does.

Providing a notification that the action was denied (if it was denied).

You mean specifically for clipboard paste, or for any qrexec service in general?
If the latter, IMO there should be also an option for silent deny - for example I don't want a notification about denied qubes.InputKeyboard every time I plug in my yubikey...

[andrewdavidwong]

Default policy file already have it: https://github.com/QubesOS/qubes-gui-daemon/blob/master/gui-daemon/qubes.ClipboardPaste.policy

Note the comment about "ask"/"allow" there. For dom0 as a source it doesn't matter in practice, but for other domains it does.

The original behavior I reported happens with a policy file that looks like this:

#dom0	$anyvm	deny
[...]
$anyvm	$anyvm	ask

The dom0 line is commented out. In this case, shouldn't the last line apply to dom0? In other words, shouldn't Ctrl + Shift + V in the target VM work after using the "Copy to Dom0 clipboard" button?

Providing a notification that the action was denied (if it was denied).

You mean specifically for clipboard paste, or for any qrexec service in general?

Whichever one you think would be more appropriate to communicate to the user the reason that Ctrl + Shift + V is denied when the user presses it. If the user is actually pressing Ctrl + Shift + V, we can generally assume that one of the following cases holds:

1. The user intends to paste from the inter-VM clipboard into the target domain.
2. The user meant to paste from the inter-VM clipboard into a different domain and accidentally targeted the wrong one.
3. The user accidentally pressed Ctrl + Shift + V instead of a different key combination.

Suppose the action is denied due to the RPC policy.

• If case 1 is denied, the user probably forgot that the policy is set to deny this action. We should remind her.
• In case 2, the user may not realize she's trying to paste into the wrong domain. Telling her that the action is denied might tip her off that she's trying to paste into the wrong domain.
• In case 3, the user may not realize she pressed the wrong key combination. Providing the "denied paste" feedback would tell her what she pressed (Ctrl + Shift + V), which will help her to realize (if she doesn't already) that she didn't press what she meant to press.

If the latter, IMO there should be also an option for silent deny - for example I don't want a notification about denied qubes.InputKeyboard every time I plug in my yubikey...

In the case of Ctrl + Shift + V, at least, I think a notification that occurs each time (but only each time) that Ctrl + Shift + V is pressed and denied would be perfect with respect to frequency (and not being too annoying). We already have one for each time that Ctrl + Shift + V is pressed and succeeds. We certainly shouldn't have verbose success and silent failure.

[andrewdavidwong]

Default policy file already have it: https://github.com/QubesOS/qubes-gui-daemon/blob/master/gui-daemon/qubes.ClipboardPaste.policy

Note the comment about "ask"/"allow" there. For dom0 as a source it doesn't matter in practice, but for other domains it does.

The original behavior I reported happens with a policy file that looks like this:

#dom0	$anyvm	deny
[...]
$anyvm	$anyvm	ask

The dom0 line is commented out. In this case, shouldn't the last line apply to dom0? In other words, shouldn't Ctrl + Shift + V in the target VM work after using the "Copy to Dom0 clipboard" button?

Providing a notification that the action was denied (if it was denied).

You mean specifically for clipboard paste, or for any qrexec service in general?

Whichever one you think would be more appropriate to communicate to the user the reason that Ctrl + Shift + V is denied when the user presses it. If the user is actually pressing Ctrl + Shift + V, we can generally assume that one of the following cases holds:

1. The user intends to paste from the inter-VM clipboard into the target domain.
2. The user meant to paste from the inter-VM clipboard into a different domain and accidentally targeted the wrong one.
3. The user accidentally pressed Ctrl + Shift + V instead of a different key combination.

Suppose the action is denied due to the RPC policy.

• If case 1 is denied, the user probably forgot that the policy is set to deny this action. We should remind her.
• In case 2, the user may not realize she's trying to paste into the wrong domain. Telling her that the action is denied might tip her off that she's trying to paste into the wrong domain.
• In case 3, the user may not realize she pressed the wrong key combination. Providing the "denied paste" feedback would tell her what she pressed (Ctrl + Shift + V), which will help her to realize (if she doesn't already) that she didn't press what she meant to press.

If the latter, IMO there should be also an option for silent deny - for example I don't want a notification about denied qubes.InputKeyboard every time I plug in my yubikey...

In the case of Ctrl + Shift + V, at least, I think a notification that occurs each time (but only each time) that Ctrl + Shift + V is pressed and denied would be perfect with respect to frequency (and not being too annoying). We already have one for each time that Ctrl + Shift + V is pressed and succeeds. We certainly shouldn't have verbose success and silent failure.

[marmarek]

The dom0 line is commented out. In this case, shouldn't the last line apply to dom0? In other words, shouldn't Ctrl + Shift + V in the target VM work after using the "Copy to Dom0 clipboard" button?

No, dom0 is special in here - $anyvm doesn't apply to it. See https://www.qubes-os.org/doc/qrexec3/#qubes-rpc-administration
This is why default policy for this service have this additional line.

We already have one for each time that Ctrl + Shift + V is pressed and succeeds. We certainly shouldn't have verbose success and silent failure.

Makes sense.

[marmarek]

The dom0 line is commented out. In this case, shouldn't the last line apply to dom0? In other words, shouldn't Ctrl + Shift + V in the target VM work after using the "Copy to Dom0 clipboard" button?

No, dom0 is special in here - $anyvm doesn't apply to it. See https://www.qubes-os.org/doc/qrexec3/#qubes-rpc-administration
This is why default policy for this service have this additional line.

We already have one for each time that Ctrl + Shift + V is pressed and succeeds. We certainly shouldn't have verbose success and silent failure.

Makes sense.

[andrewdavidwong]

No, dom0 is special in here - $anyvm doesn't apply to it. See https://www.qubes-os.org/doc/qrexec3/#qubes-rpc-administration
This is why default policy for this service have this additional line.

Ah, so what happens when the only dom0 line is commented out? Is it the same as dom0 $anyvm deny?

[andrewdavidwong]

No, dom0 is special in here - $anyvm doesn't apply to it. See https://www.qubes-os.org/doc/qrexec3/#qubes-rpc-administration
This is why default policy for this service have this additional line.

Ah, so what happens when the only dom0 line is commented out? Is it the same as dom0 $anyvm deny?