5 ms·
X11 had the distinction between trusted and untrusted X11 clients basically forever. But nobody bothered to even spend the minimal amount of work to make this u
by uecker 1y ago
X11 had the distinction between trusted and untrusted X11 clients basically forever. But nobody bothered to even spend the minimal amount of work to make this usable in practice^1.
This had two reasons: 1.) It is irrelevant when you run the programs as the same user so nobody bothered (and no: Wayland does not help: https://github.com/Aishou/wayland-keylogger https://github.com/Aishou/wayland-keylogger) 2.) It is more fun to simply pretend it is unfixable broken and write something new (something any good engineering manager should have stopped immediately).
¹. I used to use this and also fixed some bugs in some programs. The main problem when I last checked a decade ag was that some important extensions such as composite would need to be exposed to untrusted clients.
- rich66man 1y ago> something any good engineering manager should have stopped immediately Who exactly should and can control the horde of OSS developers?
- DarkmSparks 1y agoThey were paid by redhat.
- justin66 1y ago[flagged]
- deleted 1y ago[deleted]
- Jasper_ 1y agoThat Wayland keylogger is not the same thing. X11 has several mechanisms (XTest, XRecord, XI raw inputs) to receive a global raw key input stream, accessible to anyone who connects to the X server, without even making a visible window surface. It even bypasses grabs, meaning that your lock screen password entry can be snooped on. The Wayland keylogger acts like an application; all Wayland compositors will only send key events to the focused surface, so the user has to focus an active surface in order to get key events. Even in the scenario where you've LD_PRELOAD-hooked all applications, you still will never get the lock screen password, as the compositor never sends it out across the wire. LD_PRELOAD is problematic from a security perspective, but it's not Wayland-specific: the same issue is true for CLI applications and X11 applications, and any attacker with the ability to write files could also just replace your binaries with malicious ones (stuff them somewhere into ~/.hidden, and then add a $PATH entry to the start).
- uecker 1y agoI think you did not understand my point. X11 has several such mechanisms, yes, but it also has the concept of untrusted clients that disallow the use of these mechanisms and could be used to provide safety similar to Wayland. The point is that this mechanism of untrusted X clients was neglected and I gave an explanation way.
- froh 1y agoYes and your response in the whole thread reading top to bottom was the first one that really taught an old dog a new trick. I've been using gnu on x11 since 1991, been annoyed by fellow student's audio streams on my work station back then, and I've never heard about trusted vs untrusted x11 apps. I wonder how this debate was mainstream? did some gamers try to squeeze 3 extra percent by taking the protocol out of local stacks? there must have been better ways to do that, without throwing out all X11 benefits? to this day I'm annoyed I can't have a decent window manager integration on gWSL because the compositor doesn't implement the full window manager protocol.
- uecker 1y agoSee the ssh manpage for an explanation of untrusted/trusted clients. This debate was mainstream. Basically, some people presumable paid to work on Linux graphics decided to implement something new instead of doing their job, and gave talks about why X is fundamentally broken. I believe the driving force might have been the hope to support Linux on mobile or embedded devices, and X seems just unnecessary (although I think network transparency would be super useful on mobile devices). Some gamers certainly believed nonsense such as "all X programs are forced to use ancient drawing primitives and so programs will be much faster with Wayland". Wayland developers certainly did not do anything to stop such misconceptions. Later there was disappointment because obviously it was not faster (the drawing model for modern clients is essentially the same), but other myth such as the "fundamental security issue" prevailed.
- ElectroBuffoon 1y ago
- jeroenhd 1y agoAs far as I can tell, enabling the trusted/untrusted security feature breaks a lot of basic features, including clipboards, XRandR, GPU acceleration, XKB keyboard layouts, and whatnot. It's theoretically available but practically useless. Xnamespaces looks to be more promising, but as far as I can tell that's still a WIP with little documentation, and from the documentation I can find it looks like it still breaks things like clipboard functionality.
- 1718627440 1y agoWell, the threat is shared access to resources like clipboards, so securing against this of course breaks the clipboard. Pick your poison.
- bmacho 1y ago> Pick your poison. Permission system? X11 with a permission system is the next logical step for Unix graphics. There is absolutely no need to break 40 years of graphic software, or throw away 40 years of accumulated features.
- 1718627440 1y agoYes, but even a permission system can only give a program access to the clipboard or not. You can't deny a program access to the clipboard and complain that the clipboard doesn't work.