The X11 SECURITY extension from the 1990ies

blog - git - desktop - images - contact

---

2025-08-02

It's widely known that X11 has a problem with, for example, keyloggers. The issue is not that keyloggers are possible through security holes -- but keyloggers are trivial on X11, as they are part of normal operation and don't require exploits. It is one of the reasons why people push for Wayland.

I recently came across the X11 SECURITY extension, which is part of a normal X.Org installation.

Quick overview of the extension

In short, it allows you to put X11 clients into two classes: "Trusted" and "untrusted". Untrusted clients cannot interact with trusted ones. It does work the other way around, though, for example I can use multipass to type from a trusted client into an untrusted one.

So, you might think about classifying your browser as untrusted and then, when there's a security issue in that browser, it cannot use the active X11 connection to spy on your keyboard.

I wanted to see how well this works in its current state.

"Current state" might be a bit misleading. The extension is quite old and it looks like nobody did any substation work on it for ... a long time.

The thing is that it's immediately clear that this extension -- in its current state -- is not the answer to "X11 is insecure": You only have two classes, trusted and untrusted. That's not enough. For example: When you run your browser as untrusted, you can't simultaneously run some sandboxed program (Snap, Flatpak, ...) in a meaningful way, because those two clients can spy on each other again. You want a proper per-client isolation instead.

Sandboxing plays an important role here. If you run programs "the traditional way" (i.e., full access to the filesystem and network), then an attacker can do all kinds of things and X11 keylogging is just one of a million concerns.

How to classify clients as untrusted

Here's Xuntrusted, a slightly modified version of a script that I found:

#!/bin/sh set -e keyfile=$(mktemp) trap 'rm "$keyfile"' EXIT # Key will be deleted from server 60 seconds after a client has last # used it. xauth -f "$keyfile" generate "$DISPLAY" MIT-MAGIC-COOKIE-1 untrusted export XAUTHORITY="$keyfile" "$@"

(Again, if you don't use additional sandboxing, then this is pointless, because an attacker could look for the original key file in the filesystem.)

And then do something like Xuntrusted xterm. Oops. That already doesn't work:

$ Xuntrusted xterm xterm: warning, error event received: X Error of failed request: BadAccess (attempt to access private resource denied) Major opcode of failed request: 104 (X_Bell) Serial number of failed request: 527 Current serial number in output stream: 533

My terminal xiate fails with a similar error.

What does work is qterminal, for example, or ... drumroll ... Firefox.

What does it protect against?

I would like to give a list of ways on how to do keylogging on X11, but even though this is just normal operation on X11 and doesn't require any exploits, such a list might be problematic, so I'm not going to. You have to do your own research and run your own tests. I understand that this means this blog post lacks substance.

What I can say is that none of the keylogging techniques that I found work anymore when clients are untrusted.

Side effects: Things that break

As we've seen above, some clients simply can't cope with the situation at all and crash.

Also, I'm currently running my Firefox as untrusted. That works remarkably well. Except for ...

• ... the clipboard. Untrusted clients can only communicate with other untrusted clients, hence the clipboard mechanism is essentially broken. You can still use the clipboard inside of Firefox or with other untrusted clients, but nothing else.
• ... most other X11 extensions. When a client is untrusted, it only has access to these other two extensions. Hence,
  • qterminal complains about XRandR being unavailable (which it maybe uses to do scaling, I don't know),
  • Firefox is a bit slower than usual,
  • my keyboard layout doesn't work, probably because the XKB extension is unavailable.

The most painful issue is the clipboard, I think. While I wrote this blog post, I had Firefox running as untrusted. I was not able to copy all those links from the browser to my Vim -- I had to resort to running http-collect, a little web app with an HTML form where I can POST data, and then read the resulting files in Vim. That is obviously not feasible in day to day life.

With the GLX extension not available, 3D programs probably won't work:

$ Xuntrusted ./rtspeccy_alsa freeglut (rtspeccy): OpenGL GLX extension not supported by display ':1' $ Xuntrusted glxgears Error: couldn't get an RGB, Double-buffered visual

Xuntrusted dosbox does work, though.

Conclusion

In its current state, I'd say the SECURITY extension is "somewhat useful", but more work would have to be done. Both in X.Org and in the clients. You would have to come up with a new clipboard protocol, for example. And the list goes on. (See where I'm going with this?) It's not that simple.

If anything, this extension could have been the foundation for or a first step towards client isolation on X11 -- if it had been widely adopted decades ago, when it originally came out. Even if it had meant breaking older clients (or introducing something like "X11X12" like we have with "XWayland" these days), I believe that it could have been done. I suspect that this didn't happen because sandboxing desktop applications was hardly done by anybody back then, so nobody saw the need. This is a thing today, but now we have Wayland which has gained much more traction. The "X11 SECURITY extension"-ship has most likely sailed.

But it's still interesting to see that this thing exists.