Qubes Clipboard transfer limited size of text

[Nurmagoz]

Qubes OS version

4.0.1

Affected component(s) or functionality

Qubes Clipboard VMs fetcher?

Brief summary

Copying large texts will show 0 bytes in return, and not copying anything.

To Reproduce

Go to any .txt with size lets say 100mb then select all ctrl+a and then ctrl+shift+c it will show 0 bytes been copied

Expected behavior

It should copy the text regardless its size

Actual behavior

Doesnt copy it

Screenshots

N/A

[marmarek]

The limit is intentional, to protect both disk space, and target application you paste it to. It's about 64k

[Nurmagoz]

any easy method to increase that ? at least it should be an optional.

Making it as a default sound fine , making it unchangeable sound unusable to some extent.

[marmarek]

You can transfer larger data using a file. If your use case is dom0 yournalct, then you can do qvm-copy-to-vm from dom0 too. BTW looking at your next report #5221 , this is exactly why the limit is there - it's way too easy to break arbitrary application by simply pasting a lot of data.

[Nurmagoz]

because there is a bug and i need to search in the logs which i copied to.text in Dom0 i cant do that because there is no gui file editor in dom0(which i like to use more than UI like nano or vim).

[sjvudp]

any easy method to increase that ? at least it should be an optional.

Making it as a default sound fine , making it unchangeable sound unusable to some extent.

Well, I'd consider 100 MB a bit large, but 64kB also a bit small. The typical user doing cut&copy|paste will have small chunks, agreed, but (just for example) in X11-Emacs it's quite easy to make a big selection (e.g. to copy text from one window to another). Why not make the limit configurable? After all we don't have a 16-bit system here...

[adrelanos]

Could this limit (optional or setting) please be increased to something more reasonable let's say... 10 MB?

[DemiMarie]

@marmarek thoughts?

[unman]

I would not be in favour of raising the limit - 10MB does not seem "reasonable" to me, even as an optional setting.

[brendanhoar]

The limit is intentional, to protect both disk space, and target application you paste it to.

Is the implication here that clipboard data is being saved to dom0 filesystem when clipboard copying from domU A to domU B?

If so, is this really necessary?*

If not, what is the disk space concern?

B

• again, forensics concerns; dom0 shouldn't purposefully store data that isn't necessary.

[sjvudp]

I think the minimal fix would display some message if the selection is larger than the capacity of the buffer (i.e.: the copy is incomplete).

[logoerthiner1]

The limit is intentional, to protect both disk space, and target application you paste it to.

Is the implication here that clipboard data is being saved to dom0 filesystem when clipboard copying from domU A to domU B?

If so, is this really necessary?*

If not, what is the disk space concern?

B

* again, forensics concerns; dom0 shouldn't purposefully store data that isn't necessary.

See https://github.com/QubesOS/qubes-gui-daemon/blob/8552d9984efd5017799d526b3c1d13c76c7e0022/gui-daemon/xside.h#L29, when you "Ctrl-Shift-C", the clipboard will be stored inside dom0 /var/run/qubes/qubes-clipboard.bin file. There seems to be an alternative implementation of clipboard (qrexec) but this does not seem to be used actively.

I do not understand in detail the security consequence of storing a controlled blob inside a LUKS-LVM-ext4 partition (/var/run/qubes is not a tmpfs if I get it correct). However it is a valid point to consider that storing clipboard data to that place is suboptimal for forensics concerns.

The source code is really old. I guess that the decision with a /var/run/qubes/qubes-clipboard.bin was done when Qubes OS was ever born. (The last editing of that line is 6 years ago where the line was in xside.c, and another 3 years ago the dash was underscore then.)

Anyway it may not be late to reconsider the design.

[rustybird]

/var/run/qubes is not a tmpfs if I get it correct

/var/run is a symlink to the /run tmpfs.

[logoerthiner1]

/var/run/qubes is not a tmpfs if I get it correct

/var/run is a symlink to the /run tmpfs.

Yeah you are right. Then there should be little forensics concerns unless one considers the possibility that tmpfs file is swapped (this could happen though; dom0 is not short of interfaces that can at least give dom0 memory pressure, for example qubes-gui-daemon). "Disk space" is misleading here - actually the capacity of tmpfs is limited mostly by memory space.

[alimirjamali]

PR for #9296 should fix half of this issue (configurable global clipboard size per GUIVM and/or per qube up to 256KiB). This already quadruples the existing limit.

Over that amount, we have to decide if X11 INCR protocol has to be supported for inter-vm clipboard mechanism. If not, simply reject it. But since the patch for #9296 is relatively big and hard to review, it would be better to wait for its conclusion before dealing with INCR.

[alimirjamali]

PRs #9296 now covers all of this issue.

Patch to gui-daemon creates a .metadata JSON file which includes comprehensive information for Global Clipboard systray widget.

For the handling of X11 INCR (clipboard size over 256KiB), the patch to gui-agent converts it to a meaningful warning rather than sending a meaningless byte.