Consider clipboard diode restrictions to selectively allow cross-container clipboard sync

[Intensity]

Given the use case of running multiple x11docker containers simultaneously, I'll suggest the possibility of restricting the flow of information between these containers by leveraging a declarative approach.

Let's assume for now that running x11docker containers are tagged with a property, like role:work, role:shopping, role:source (a source container with passwords for example) or role:sink (for archiving).

With the principle of least privilege to hand, a user may identify a frequent need to send clipboard contents from a certain class of containers to another, but not necessarily in the reverse direction. I mention the tag/property system because it would make it easier to spin up a new container that inherits the same permissions with respect to clipboard sharing, without requiring the overhead of redoing that configuration for a very similar container. The user could find their own way of binding a key sequence to quickly configure permissions, and so if x11docker provides a command line interface for this configuration, this may be sufficient. That is, a full-fledged UI wouldn't be needed for the base functionality. Directives can be allowed to specify the flow of information, whether that's a permenent flow or temporary; and then other directives can be allowed to facilitate the actual copy and paste commands (although the latter could be triggered by events such as clipboard read/write).

Suppose by default all sharing is blocked. But a user may want to enable sharing from role:shopping to role:sink so that they can archive the URL from a shopping container freely. The one way nature of this declaration would prevent role:shopping from seeing any other clipboard shares unless explicitly permitted. Another kind of share might be time-bound: say for 30 seconds, clipboard contents would be available, but after that point, all clipboard contents in all applicable containers becomes cleared to the null string, for all "selection" mechanisms (using xclip terminology). That way, a password can temporarily be propagated from a password-manager container (say that it's in role:source) to a container that's using it (in this case, role:shopping) and then this flow is allowed temporarily while others are blocked by default.

The automatic clearing of contents when the contents have been successfully shared (or after a time bound) would increase security, especially since the user may not always be inclined to clear contents in multiple containers manually, and for all selection mechanisms. I'm not sure if it's possible to detect when the clipboard contents were consumed (by a "paste" command) but if so, this could make the use of the data one-time.

In considering this, other functionality can also be evaluated for inclusion. There might be other projects aimed at clipboard sync, both local and remote, and thus a comparable interface used in multiple cases. Also, a very lightweight layer of encryption could be used to grant even greater security and prepare for a future-scoped possibility of sharing information across host boundaries. Say for example based on faster elliptic curve primitives for speed. But much like GnuPG allows for multiple recipients, a clipboard content that is allowed to be "read" by more than one tag can encrypt the ephemeral symmetric key for various asymmetric key recipients. Still, the data can be kept in RAM only for good measure (although if the host uses unencrypted swap this justifies the importance of encrypting the data for safety).

Any time I copy and paste, that particular need to do so drops after a minute when the paste is complete. And so a periodic process that automatically clears contents of all clipboard selections in all containers would itself be an important enhancement, because this focuses on the minimal requirements of that copy/paste only. However I also suggest some advantages of allowing clipboard sync to be a declared as an opt-in property. I also may want to copy from a certain container's clipboard into another container's clipboard but in such a way that the host itself never needs to see those contents. Stepping back, perhaps a subsystem of copy/paste, if implemented could allow for other enhancements, like transparent interoperability between various environments.

[mviereck]

Thank you for the suggestions! I fear this goes over the scope of x11docker.

However, a separate tool for this would be quite nice.

Clipboard handling is not part of the container area but entirely handled by the X servers. Normally only one X server is running and provides the clipboard to all of its clients.

x11docker runs additional X servers. It uses xclip to watch the clipboard of both X servers, and if one X server gets new clipboard content, it is sent to the other X server using xclip. (This is the case with e.g. --xephyr, but not with --xpra and --nxagent that have their own clipboard mangement.)

So your request is about clipboard handling of multiple X servers (with all the possible features you've mentioned). It seems there is no tool in the wild that provides this, I've already searched a lot previously.

If you find such a tool or even develop one yourself, I would appreciate it very much!

[mviereck]

I have added some optional arguments to option --clipboard for better isolation and security. From x11docker --help:

 -c, --clipboard [=yes|no|oneway|superv] Share clipboard. Possible arguments:
                         yes:    Share clipboard in both directions.
                                 Includes middle-mouse-click selection.
                         oneway: Copy clipboard from container to host only.
                         superv: Keys [Super][V] copy clipboard from host to 
                                 container. Does not copy middle-mouse-click
                                 to container. Otherwise same as 'oneway'.
                         no:     Do not share clipboard.

With --clipboard=superv it should be secure and useful at the same time. The container only gets host clipboard content if one presses keys [Super] [V] while a container window is in focus. On the other way around, the host always gets clipboard content from container without further user action. This option needs xbindkeys additionally to xclip.

This is not as advanced as you have suggested, but I assume it covers most use cases while still being easy to handle.