At the moment, the only restrictions we have on clipboard data transfers are:
MAX_CLIPBOARD_PACKET_SIZE = 256*1024
Any clipboard zlib-compressed data larger than 256KB is simply dropped with a log warning. Maybe this limit is too low? We can raise it with #275
discard_targets = ("SAVE_TARGETS", "COMPOUND_TEXT")
It would be nice if we could inject more filters, say:
Here is a hardcoded regular expression filter which will block any string containing the word "virii":
--- src/xpra/platform/clipboard_base.py (revision 2850) +++ src/xpra/platform/clipboard_base.py (working copy) @@ -123,6 +123,10 @@ ints = struct.unpack(binfmt, data) return "integers", ints elif dformat == 8: + import re + if re.match("virii", data): + log.info("virii string blocked: %s", data) + return None, None return "bytes", data else: log.error("unhandled format %s for clipboard data type %s" % (dformat, dtype))
This is just an example, but it shows how trivial it would be to pattern match the keyboard data and discard data. It only filters on the way out, but I don't think we really care about the way in: if you connect to a malicious server, surely you have bigger problems? We'll need to check every possible (..) clipboard transfer to make sure that data isn't transferred using some other encoding which would defeat the filter. Does it work with "utf8" and "latin1", what about other encodings?
Now, I'm not sure how we can make this customizable by the user, maybe:
With a list of regular expressions stored in this file? And maybe we could ship a default file too, maybe in
Or maybe we want to have different actions (one per file, or specified for each regex): drop (just harmless stuff that we want to ignore), alert (dangerous stuff that we want to warn about), ..
The python regular expression module is documented here and supports all standard regex constructs.
--clipboard-filter-file=filename Name of a file containing regular expressions, any clipboard data that matches one of these regular expressions will be dropped. Note: at present this only applies to copying from the machine where this option is used, not to it.
This is only hooked for the server: copy from server is filtered, copy from client is not. It probably makes sense to do that too?
Here's how to test:
echo virii > clipboard-filter.re xpra start :10 --start-child=xterm --clipboard-filter-file=./clipboard-filter.re
clipboard buffer contains blacklisted pattern 'virii' and has been dropped!
That's assuming that you have a client with good clipboard support (ie: Linux) - if testing with win32, the ongoing bugs may interfere with the testing.
I think that we also need to look at filtering clipboard targets (similar to #273) or at the very least verify that the targeted applications cannot avoid the filtering simply by transferring the text using rtf/utf16/whatever.
With an ubuntu (12.04) client the clipboard filter seems to work, but there is an element of confusion as attempts to paste yield nothing and no message. (For a few minutes I thought the linux clipboard was broken too.) For a user without a server display handy, you can imagine the reaction.
viriibnand got nothing back out. Whether this is the behavior we're hoping for should be decided.
With a windows client, aside from the "expected" clipboard issues, the filter seems to drop copies from a browser window (chrome, whatever) but doesn't seem to catch/drop anything coming in from an xterm. (More headaches. Be sure to filter data transferring from
Primary as well as
Clipboard. (Is there a mysterious win client clipboard mechanism that is using different procedures that need to be found when getting data from
I don't see much point in specifying "
^virii$" to match the lone word exactly, but feel free to try it.
SECONDARYto/from the server at all now, so the fact that those are not filtered is expected behaviour: the data stays on the server - xterm selection goes to
PRIMARYand stays there. We are not going to be filtering that, doing so would be ridiculously difficult since we would need to monitor the clipboard when we do not own it and "force clear" it when we do not own it - not good behaviour, not one that is expected to work well or reliably.
With a windows client, you can paste from an xterm's
primary to the client. I'm not sure if that's a copy that I or anyone should really worry about filtering (as opposed to copying from browsers). I brought it up in case anyone else could (probably) think of a reason why it should be filtered.
If no one can think of a reason, then I guess this filter is functional, and remains only for everyone to try to maintain a file of all the things they'd like to filter from clipboard use.
If you can copy anything from
PRIMARY then this is a bug that I cannot explain (and cannot reproduce) and it should go under #272 not here (this ticket is about filtering).
If that's the case and filtering does work as intended, then please close this one and follow up there.
Plase follow the simple steps below to see if it still copies data from
PRIMARY, and if so, post the client clipboard debug output log by running both ends with
Here is how I test:
gtk_view_clipboard.pyfrom this xterm
gtk_view_clipboard.pytool, verify that the selection has been copied to
CLIPBOARD(using the "
GetString" button for each type of clipboard)
icon we could use to flash the system tray when content is blocked
I can still copy from xterms to windows client. I've commented that in 272. The clipboard filter seems to work as advertised though, so I will close this as resolved.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/274