Improving Clipboard security

[cepelinas9000]

Improving Clipboard security.

This more like draft of draft and probably will do in some form in my free time on slowpoke speed, but it more like to start discussion if it is remotely sensible and I am not very familiar Xserver - thus i can totally miss logic.

I want start discussion from Clipboard security as it is look easier to implement proof of concept.

In 2025 is not malware problem main problem, but random proprietary software, which goes like "We value your privacy, our tool are enchanted by AI and in order to deliver 100% genuine experience we need send to our servers following information: all your keyboard keystrokes, all clipboard, periodic screen shots, network information (we will scan your network and maybe inform about vulnerabilities), your pictures from camera and so on."

The idea of security lies on 2 points:

• The clipboard data have additional attribute to describe data kind, for example call: SetSelectionOwner(selection=PRIMARY, owner=Window, time=timestamp, data_kind=PASSWORD) or data_kind=COMMON
• The application have something like trust_factor, it set by window manager and can be overridden by user. It for policy impact, if SetSelectionOwner with data_kind=PASSWORD is set and untrusted application wants to read clipboard - the window manager explicitly waits for user action to allow access data (example in picture below)

The low effort example for waiting user approval to access clipboard

---

For start data_kind, can be:

• CONFIDENTIAL - always needs user approval
• PRIVATE - only fully trusted programs doesn't need user approval
• PASSWORD - same as PRIVATE, but contains password
• NORMAL - common clipboard,
• LOGS_ERRORS - system logs and everything: mostly technical data, where cannot easily to mine user private information
• PUBLIC - clipboard contains public data and as long as application in slightly trusted in system it is allowed to access without user knowledge

Trust factor, probably variable with following values:
0 - Fully trusted - only data_kind=CONFIDENTIAL needs user approval
1 - High trust - CONFIDENTIAL and PRIVATE needs approval
2 - Normal trust - passwords too needs approval
3 - Lower trust - message to user if clipboard accessed when window is not focused. Obvious LOGS_ERRORS and PUBLIC is accessible
4 - Guest trust - only public clipboard data available (and probably need focus)
5 - Untrusted - any interaction with clipboard needs user approval

To implement

1. By default clipboard security do nothing - everything trusted and only after controlling program sets policy, hooks it activates. But problem lies what to do before activation and when policy manager crashes...
2. The calls like "SetSelectionOwner" can be fully retrofitted, data_kind can be set as default value and for above cases the SetSelectionOwner2 is necessary
3. Need mechanism to hold X11 rpc message until user approval, i saw that is not currently implemented? or it was for very advanced cases?
4. Mostly logic goes on window manager or similar program shoulders: settings application trust factor, showing modal windows, implement policy

Any comments? It is sensible or just overcomplicated idea?

[dec05eba]

This is kinda related to X11Libre/xserver#197 (the ui prompt part mechanism), but its not part of xnamespace

[HaplessIdiot]

This is such an amazing effort you put into this suggestion. This looks like a perfect blueprint of what to do going forward, but yes it is technically already an issue as @dec05eba mentioned. I would add this post to the issue that way it gets more visibility.

[SuperDuperDeou]

I personally don't like it:

• There's a real risk of getting to the Windows Vista problem: so many popups that the users mindlessly click "accept", defeating the whole point
• Distors will likely put xclip as trusted to not break existing clipboard automations, and that's going to be an easy bypass for the whole system
• I don't see a point in restricting write access as well, when the problem is just read access

[cepelinas9000]

I didn't express clearly enough:

• The idea is not pop-ups, but modal over program window when data requested - the downside is, user need additional "Paste" click for confirmation and if program requested clipboard in background is now obvious for user. Obviously not all programs have windows
• That is compromise, It is relative easy update parent-child process relationship and apply additional rules checking process tree. As for breaking automations - you can start from sensible default and let user override if wants xclip to have full access
• My bad, I was talking about read access.

[SuperDuperDeou]

I think it can be streamlined a lot (from the user's perspective) with two reasonable assumptions:

• A focused window reading the clipboard is sane behavior
• There's no damage taken in a window reading data it itself provides

So, if the window requesting to read the clipboard is the same as the one that set it, then read permission is always granted.

Then I'd say only two confidence levels are actually needed: public (default), and confidential.
And windows only need 3 trust levels:

• Untrusted (default): All unfocused read attempts are denied (return a dummy), when focused reading public data is granted, confidential data requires user confirmation. This is where proprietary applications go.
• Semitrusted: Permission to read public data is always granted. Confidential requires user confirmation when unfocused, granted when focused. This is where most applications go.
• Trusted: All unfocused read attempts are denied (return a dummy), when focused reading public data is granted, confidential data requires user confirmation. This is specific for the clipboard manager.

That would make for the default behavior, which should probably be configurable, maybe even per selection.

A config file could look something like this:

Section "SelectionPolicy"
  Identifier "clipboard"
  ConfidenceLevel "public"
  TrustLevel "Untrusted" "public" "deny:allow"
  TrustLevel "Untrusted" "confidential" "deny:ask"
  TrustLevel "Semitrusted" "public" "allow"
  TrustLevel "Semitrusted" "confidential" "ask:allow"
  TrustLevel "Trusted" "public" "allow"
  TrustLevel "Trusted" "confidential" "allow"
EndSection

For which window is which trust level, that too has to be configured, in some way. Maybe on top of XAuth, or as part of XNamespace.

[metux]

Clipboard is one of the things already isolated by Xnamespace

[callmetango]

@metux
How is this done? I'm asking because it could help @KendricksLCamille in Enhance documentation of Xnamespace · Issue #458 · X11Libre/xserver.

[metux]

each namespace has it's own clipboards / selection buffers.

[callmetango]

Thank you!

[callmetango]

Thank you for your contribution! We currently restructured the "Ideas" discussions and accordingly this discussion will be moved to the X11Libre 4 Good Ideas For Later category.