> What does it protect against?

Unless you're doing SELinux or using some tool like firejail, absolutely nothing?

The average desktop is completely insecure, regardless of the display protocol. If a program is running as your user it's already game over: it can do whatever it likes. For example, I can simply change your shell profile to add an LD_PRELOAD shim, hook some libc syscall wrapper and run arbitrary code in any user process. There's no need to log key presses.

Keep in mind that X11 is a protocol, so the client might not be running as your user on your local machine, it could be a dedicated machine that's only running the client.

In this case, again it's not important because in our timeline X11 is old, you might proxy the clipboard feature, with a trusted and untrusted connection, the untrusted connection needs to be careful because it's exposed to arbitrary nastiness from potentially hostile untrusted clipboard-using software - the trusted one talks to everybody else. So an example is you might decide to sanitize text, strip out invisible control characters, and exclude "rich" text formats that might conceal attacks. Or you might allow some images but only after previewing them and constraining their properties, no 18GB GIFs please, yes it's technically possible to encode a huge truecolor image as a single GIF no I don't want that in my clipboard.

Is this something we should try to implement? Probably not, but in a world where people try to kite surf across the English channel it's nowhere close to the craziest hobby.

> the client might not be running as your user on your local machine

True, this is probably the only real use case. X11 forwarding in OpenSSH (ssh -X) does in fact use this extension by default.

> Keep in mind that X11 is a protocol, so the client might not be running as your user on your local machine, it could be a dedicated machine that's only running the client.

For an X server to be network exposed, you first have to either SSH forward it or remove the nowadays-default "-nolisten TCP", and then either get the xauth secret or have the user do 'xhost +'.

At that point I'm gonna say the attacker earned their keylogger access.

And you or your distro might consider patching out the TCP variant.

Saying 'xhost +menger' and being able to run graphical apps from my university's Sun server -- OPEN LOOK apps at that -- on my local Linux machine was peak 1990s computing.

Indeed https://github.com/Aishou/wayland-keylogger

This is why need need app sandboxing as the mobile platforms already do. Snaps and Flatpak both suuport this, but their critics resist without providing an alternative.

Are the mobile platforms using Snap and Flatpak?

you're right, but sec is about threat profiles. there's a point where selinux, firejail, etc. aren't enough either. even a virtual machine may as well be wet rice paper to an alphabet soup agency. you should very much assume that even airgapping isn't enough, unless it's inside of a faraday cage.

xorg security measures are a different matter from stopping any random program from writing to your filesystem. broaden the conversation to be about all security across all attack surfaces under all conditions and nothing is safe. i'm still not gonna run everything as root.

..... guix shell --container

it's great for this.

X11's SECURITY extension was its long-forgotten stab at sandboxing: flip a bit and every client is either trusted or untrusted. It does kill trivial key-logging, but it also breaks the clipboard, disables GLX and makes various apps fall over, leaving the desktop unusable while Firefox somehow works just fine. A cool reminder that X11 could've had proper sandboxing 25 years ago, but the UX cost sank it and Wayland is the lifeboat now.

I remember back then xauth didn't even exist. You could simply dump a window on anyone else's screen. It was heaven for practical jokers like me.

To me it seems the security extension is more useful for protecting elevated prompts (such as running an application as admin) than actually sandboxing between applications.

If that extension never caught on, then what mechanisms are being used now to protect elevated prompts/apps?

I think a proxy server might be a better way to handle security, than the way it is done as described in this article. (On a computer, the security will need to consider more than only the X server, but that will be one part of it.)

> 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.

Sorry, but did I miss news about a keylogger epidemic? On Linux?

In all seriousness, is this solving an actual problem or an imagined one?

And even assuming a 'Yes': A problem that isn't better solved elsewhere? How did the keylogger get access to the system and its desktop session? What else does it have access to?

Firejail discusses this briefly in their X11 guide:

The sandbox replaces the regular X11 server with Xpra or Xephyr server. This prevents X11 keyboard loggers and screenshot utilities from accessing the main X11 server.

https://firejail.wordpress.com/documentation-2/x11-guide

It's not a common issue, but obviously a security concern to make it so easy for keyloggers to record your keypresses or screen. I currently prefer X11 to Wayland, and I'd love if this problem was possible to address without Firejail. I use Firejail for other sandboxing tasks, but sandboxing X11 is too impractical.

That's not an answer. Yes, I can run xev on my machine against my X session and see my keystrokes. It is not obvious that this is a problem. A more plausible angle would be that if an attacker compromises one application - say, a web browser - then they could keylog passwords. Of course, most people don't sandbox their browser so that's the least of their problems if it's compromised (ex. https://access.redhat.com/articles/1563163 let an attacker steal ssh keys).