Hard for me to take that one seriously.. For example they call out byte swapping for endianness as the type of cruft holding back X11. Such a trivial thing to be concerned enough to put in the readme... (I guess Phoenix is also putting this..) Seems like mostly authored by Claude too.
This is a problem in many projects now. xserver and mruby for instance also succumbed to claude. It seems claude is the ultimate virus. It leaks into almost every project now. So I am not sure it can be used as differentiating criterium here merely for being claude AI slop. I've noticed a lot of documentation is now totally useless though; claude slop is just unreadable to me. It's like a person who is not able to think, wrote the documentation. I did not have this issue back when real humans wrote documentation, even though high quality documentation was always rare anyway. But, for instance, Jeremy Evans in his projects tends to write high-quality documentation in general, and I can understand it fine, whereas if you look at matz spinel, I have no idea what the AI slop in the README is really trying to convey. Or on ffmpeg, a german dev used AI slop to try to create some proposal, and someone else pointed out that this is pointless and impossible to read and understand, yet the original guy did not understand why real people don't want to be AI slop spammed. It's very strange.
For an article written late last year I hoped for a little more awareness of how massive a security hole granting full, unfiltered access to the X11 server is. Granted, any sandboxing is better than none, but firefox is one of the few apps that already sandboxes itself really well, and with a blog title like that it might be good to touch upon things like nested X servers such as Xephyr.
> Xeyes is cute until one considers the practical implications…
what's the problem with xeyes? it reads data on your computer and displays it. Just like vim or cat.
If, for some reason, you want to run a program that you don't trust, you should sandbox it from the outside. But granting full rights to distro-provided programs like vim or xeyes is perfectly sane. Just like you trust your kernel.
> But granting full rights to distro-provided programs like vim or xeyes is perfectly sane.
You mean run everything distro-provided as root?
There are reasons systems don't do that any more. Even distro-provided services are often setup in a way to no run with full rights. Can you imaging reasons why this is done?
What was neglected is doing the same on user level, which should be done for pretty much the same reasons.
> But granting full rights to distro-provided programs like vim or xeyes is perfectly sane
Saying this after the whole XZ utils ordeal has happened is quite interesting.
Can you really guarantee that your distro is not compromised? And if it is compromised, how can you easily _discover_ that a program is doing something strange?
X11 (the one that most people are familiar with, not the locked down one with X security -- because the latter introduces compatibility issues) does not have an access control model where programs can request for specific permissions.
In other words, xeyes would just work(TM) without the user granting it permission to read global mouse pointer position. And simultaneously, the same is true for $compromised_distro_provided_program.
1 malicious package almost got distributed in 20 years of debian history?
>granting full rights to vim or xeyes
I'm not sure I get what's being discussed here. Standard Xorg runs without root already. And Xeyes definitely 100% run without root, I get why you would you run vim on root, to edit root files, but also don't? Especially if you have plugins, run simple programs like echo>> , ed, grep or nano.
Obviously, XZ happened on Debian. But $malware can occur on any Linux distribution at any time. For a recent example just look at Arch Linux.
Also, are we still assuming that we would still get only one attack over 20 years, instead of the frequency increasing to, say, one attack per year?
---
But those are not my original point, XZ utils was just an example.
My original point is that: why should we not practice defense-in-depth, where we make sure malwares have to jump through multiple hoops (and hope that they trip on one of them!) in order to launch an attack?
>I'm not sure I get what's being discussed here
I think it's the implication that any GUI program running under X can see any other GUI program and watch the user's interaction with the other programs. Vim is a CLI program though though...
It is the same issue with all sandboxing solutions. If your program does not work without giving it excessive permissions, it does not work. If we want to move to a version with minimal privileges, X would still seem like a good platform to work on this. But one would have to work on it, not decide that everything needs to be rewritten all the time.
> If we want to move to a version with minimal privileges
Then you would have to cut everything provided by the X protocol into many, smaller, controllable pieces. Because if the permission control is just a switch that says "ability to communicate with the X server", then the whole exercise is rather moot, isn't it.
And when you cut the protocol into smaller pieces...
No, there is already a secure mode which in the past worked fine but was bit too restrictive for modern clients, and there already exist hooks for fine grained access control.
This is false. A process needs read permission on the relevant `/dev/input/` device, typically by running as root or as a user in a group like `input`. Normal desktop users generally should not be in the input group. Regular applications receive keyboard input through the compositor/windowing system.
Correct me if I'm wrong, but passing through the X socket gives a giant sandbox escape as any application can control/see any other application, including a root terminal in a GUI app.
It is my understanding that XACE doesn't actually provide any security features itself. It just provides the "hooks" to implement security extensions. Like LSM feature in Linux kernel. You have to install a additional X11 extension to do something useful with it.
So the most common X11 security extension is going to be xcsecurity which enables the SECURITY extension. It allows a course permission model were applications can be designated as "Trusted" or "Untrusted". That is going to show up in many Linux distributions.
However all applications default to "trusted" because if they are untrusted they tend to cause lots of other annoying problems and crashes a lot of apps, apparently.
In practice the only place it shows up is if you are using "ssh -X". That uses the security extension by default. Which is why there is also a "ssh -Y" that disables it for applications that it breaks.
This sort of thing is why to fix X11 security you have to give up backwards compatibility and create a new X version.
Oh, wait, that is what the X developers did with Wayland.
for example standardized window management, left as an exercise to the GUI lib and the compositor? and woop woop X11 GUI apps need to be rewritten to support window management on WSL (Wayland based) and the network reconnect on hybernate also broke.
This is rather incomplete. For instance, gtk devs already threw out tons of old code in GTK4. Wayland also has fewer features than xorg; and there are also fewer choices available. I noticed this with regards to WMs/DEs. I am not even going to issues wayland has with regards to certain video graphics - that's another not mentioned issue here.
You are trying to pick individual cherries.
> This sort of thing is why to fix X11 security you have to give up backwards compatibility and create a new X version.
Let's have a look in a little while. I myself hope for better and more transparent information at all times. Probably others want better security overall. Would it not be somewhat interesting if wayland were to be abandoned eventually due to having too few useful features compared to xserver?
> Wayland also has fewer features than xorg; and there are also fewer choices available
Because Wayland is a strictly a window management protocol focused on policy over mechanism.
> I am not even going to issues wayland has with regards to certain video graphics - that's another not mentioned issue here.
We also aren't going to mention issues Xorg or XLibre have with some graphics setups, because that's neither here nor there. This is a thread about security.
> I don't think so: <XLibre github repo link>
Didn't XLibre break some applications when launched?
> Would it not be somewhat interesting if wayland were to be abandoned eventually due to having too few useful features compared to xserver?
It would be interesting to see Wayland abandoned for a better protocol/set of protocols, xserver is neither a protocol nor really better.
> In practice the only place it shows up is if you are using "ssh -X". That uses the security extension by default. Which is why there is also a "ssh -Y" that disables it for applications that it breaks.
Unless your distro changes the default to make "ssh -X" and "ssh -Y" behave the same which popular distributions do.
Most of the time applications can read each other's memory, so protecting the display does not make much sense.
Basic X client isolation (not using XACE just Xsecurity) would have worked for sandboxed applications with some minor changes (allowing access to some basic modern extensions, I had a local patch for this once). There is really not fundamental issue in X that could now allow isolation of clients.
I wish I lived in a world were you didn't have to sign contracts, lock your doors, or have X11 security. It is so fun to run xmeltdown a new user's display.
In the end Red Hat failed to kill off X11. Let's see what happens next. The
GTK devs already rejected patches for maintaining the toolkit further for the
xorg platform, following their "GTK5 will no longer support x11" agenda. Would be kind of great to have a universal GUI toolkit that would
work rather than have toolkits controlled de-facto by private companies who just willy-nilly throw out support for this or that platform at their own selfish discretion. Though,
someone else now helps maintain gtk2, though most of the patches are in regards to
fixing bugs, ensuring that it can be compiled and so forth. https://git.devuan.org/Daemonratte/gtk2-ng
The problem is that Wayland just isn't a compelling alternative for many people, so they don't move. For me, I see no benefit because I got used to avoiding HiDPI and don't have a mixed-DPI workspace. For some bizarre reason they made each compositor implement input-handling separately, so for example artists might have to switch compositor just to use their tablet of choice. And worse yet, some people with input accessibility needs are just going to get straight up locked out of libre computing. See https://nocoffei.com/?p=451 for one example.
I have used only HiDPI monitors with X11 on Linux for about a dozen years and it has always worked perfectly.
However I use XFCE, where you can set directly the DPI values of the monitors, so that everything will work fine. I have heard Gnome users complaining about problems with HiDPI, but those are not caused by X11, but by a bad Gnome UI for desktop settings.
So HiDPI is not something at which Wayland is better than X11 and there is no reason to avoid HiDPI. At a higher DPI, OTF/TTF typefaces are rendered much more beautifully and reading becomes more comfortable.
I do not know if Wayland has any advantage at mixed DPI, because I have rarely used such configurations.
Wayland was started 18 years ago. When it was conceived, X11 was 20 years old. In 2 years, we should probably start talking about replacing Wayland with a modern display server...
In all seriousness, it is another stark reminder why you never rewrite from the ground up. Especially when you're replacing a foundational technology like the display server. In the same time Microsoft reworked their display driver model twice without requiring a single change from application developers. The Linux world doesn't have that many application developers, we should not be asking them to continually chase newer and newer APIs. A rolling stone gathers no moss.
Oh no, not this again. The design of Wayland started 18 years ago, but the stabilization happened 14 years ago, and the _convincing_ across the ecosystem obviously happened way later than that.
I would put the year closer to 2016, when distros started to consider Wayland as an option.
https://docs.redhat.com/en/documentation/red_hat_enterprise_...
https://github.com/X11Libre/xserver/blob/master/doc/Xnamespa...
edit: phoenix was the name: https://github.com/external-mirrors/phoenix#phoenix
This is a problem in many projects now. xserver and mruby for instance also succumbed to claude. It seems claude is the ultimate virus. It leaks into almost every project now. So I am not sure it can be used as differentiating criterium here merely for being claude AI slop. I've noticed a lot of documentation is now totally useless though; claude slop is just unreadable to me. It's like a person who is not able to think, wrote the documentation. I did not have this issue back when real humans wrote documentation, even though high quality documentation was always rare anyway. But, for instance, Jeremy Evans in his projects tends to write high-quality documentation in general, and I can understand it fine, whereas if you look at matz spinel, I have no idea what the AI slop in the README is really trying to convey. Or on ffmpeg, a german dev used AI slop to try to create some proposal, and someone else pointed out that this is pointless and impossible to read and understand, yet the original guy did not understand why real people don't want to be AI slop spammed. It's very strange.
XFree86, which is the "standalone DDX" you see on X11 desktops, is being actively maintained.
I have little experience with lxc but I guess waypipe could be an option too.
X itself always bothers me. Xeyes is cute until one considers the practical implications…
what's the problem with xeyes? it reads data on your computer and displays it. Just like vim or cat.
If, for some reason, you want to run a program that you don't trust, you should sandbox it from the outside. But granting full rights to distro-provided programs like vim or xeyes is perfectly sane. Just like you trust your kernel.
You mean run everything distro-provided as root?
There are reasons systems don't do that any more. Even distro-provided services are often setup in a way to no run with full rights. Can you imaging reasons why this is done?
What was neglected is doing the same on user level, which should be done for pretty much the same reasons.
Saying this after the whole XZ utils ordeal has happened is quite interesting.
Can you really guarantee that your distro is not compromised? And if it is compromised, how can you easily _discover_ that a program is doing something strange?
X11 (the one that most people are familiar with, not the locked down one with X security -- because the latter introduces compatibility issues) does not have an access control model where programs can request for specific permissions.
In other words, xeyes would just work(TM) without the user granting it permission to read global mouse pointer position. And simultaneously, the same is true for $compromised_distro_provided_program.
1 malicious package almost got distributed in 20 years of debian history?
>granting full rights to vim or xeyes
I'm not sure I get what's being discussed here. Standard Xorg runs without root already. And Xeyes definitely 100% run without root, I get why you would you run vim on root, to edit root files, but also don't? Especially if you have plugins, run simple programs like echo>> , ed, grep or nano.
Also, are we still assuming that we would still get only one attack over 20 years, instead of the frequency increasing to, say, one attack per year?
---
But those are not my original point, XZ utils was just an example.
My original point is that: why should we not practice defense-in-depth, where we make sure malwares have to jump through multiple hoops (and hope that they trip on one of them!) in order to launch an attack?
>I'm not sure I get what's being discussed here
I think it's the implication that any GUI program running under X can see any other GUI program and watch the user's interaction with the other programs. Vim is a CLI program though though...
Then you would have to cut everything provided by the X protocol into many, smaller, controllable pieces. Because if the permission control is just a switch that says "ability to communicate with the X server", then the whole exercise is rather moot, isn't it.
And when you cut the protocol into smaller pieces...
You do realize that XZ was on github. (Microsoft, PRISM etc.)
You failed at that step.
The practical implication is that every other X11 app can also read your input even when it's not in the foreground.
while being one of the few apps that executes Remote Code really well.
The author of the phoenix x server has blogged about it, iirc.
Which is configured by default on what distros?
It is my understanding that XACE doesn't actually provide any security features itself. It just provides the "hooks" to implement security extensions. Like LSM feature in Linux kernel. You have to install a additional X11 extension to do something useful with it.
So the most common X11 security extension is going to be xcsecurity which enables the SECURITY extension. It allows a course permission model were applications can be designated as "Trusted" or "Untrusted". That is going to show up in many Linux distributions.
However all applications default to "trusted" because if they are untrusted they tend to cause lots of other annoying problems and crashes a lot of apps, apparently.
In practice the only place it shows up is if you are using "ssh -X". That uses the security extension by default. Which is why there is also a "ssh -Y" that disables it for applications that it breaks.
This sort of thing is why to fix X11 security you have to give up backwards compatibility and create a new X version.
Oh, wait, that is what the X developers did with Wayland.
for example standardized window management, left as an exercise to the GUI lib and the compositor? and woop woop X11 GUI apps need to be rewritten to support window management on WSL (Wayland based) and the network reconnect on hybernate also broke.
But at least Games are faster, aren't they...
This is rather incomplete. For instance, gtk devs already threw out tons of old code in GTK4. Wayland also has fewer features than xorg; and there are also fewer choices available. I noticed this with regards to WMs/DEs. I am not even going to issues wayland has with regards to certain video graphics - that's another not mentioned issue here.
You are trying to pick individual cherries.
> This sort of thing is why to fix X11 security you have to give up backwards compatibility and create a new X version.
I don't think so: https://github.com/X11Libre/xserver
Let's have a look in a little while. I myself hope for better and more transparent information at all times. Probably others want better security overall. Would it not be somewhat interesting if wayland were to be abandoned eventually due to having too few useful features compared to xserver?
Because Wayland is a strictly a window management protocol focused on policy over mechanism.
> I am not even going to issues wayland has with regards to certain video graphics - that's another not mentioned issue here.
We also aren't going to mention issues Xorg or XLibre have with some graphics setups, because that's neither here nor there. This is a thread about security.
> I don't think so: <XLibre github repo link>
Didn't XLibre break some applications when launched?
> Would it not be somewhat interesting if wayland were to be abandoned eventually due to having too few useful features compared to xserver?
It would be interesting to see Wayland abandoned for a better protocol/set of protocols, xserver is neither a protocol nor really better.
It can't have broken as many things as Wayland
I don't want my display server/compositor to have a print server.
Unless your distro changes the default to make "ssh -X" and "ssh -Y" behave the same which popular distributions do.
Basic X client isolation (not using XACE just Xsecurity) would have worked for sandboxed applications with some minor changes (allowing access to some basic modern extensions, I had a local patch for this once). There is really not fundamental issue in X that could now allow isolation of clients.
Unless you're running everything as root, applications can not read eachothers memory.
https://github.com/X11Libre/xserver
In the end Red Hat failed to kill off X11. Let's see what happens next. The GTK devs already rejected patches for maintaining the toolkit further for the xorg platform, following their "GTK5 will no longer support x11" agenda. Would be kind of great to have a universal GUI toolkit that would work rather than have toolkits controlled de-facto by private companies who just willy-nilly throw out support for this or that platform at their own selfish discretion. Though, someone else now helps maintain gtk2, though most of the patches are in regards to fixing bugs, ensuring that it can be compiled and so forth. https://git.devuan.org/Daemonratte/gtk2-ng
0: https://github.com/joske/yserver
Plasma itself is an example of bad UI redesign (but a far cry from Gnome).
However I use XFCE, where you can set directly the DPI values of the monitors, so that everything will work fine. I have heard Gnome users complaining about problems with HiDPI, but those are not caused by X11, but by a bad Gnome UI for desktop settings.
So HiDPI is not something at which Wayland is better than X11 and there is no reason to avoid HiDPI. At a higher DPI, OTF/TTF typefaces are rendered much more beautifully and reading becomes more comfortable.
I do not know if Wayland has any advantage at mixed DPI, because I have rarely used such configurations.
Youngins just don't wanna learn it
In all seriousness, it is another stark reminder why you never rewrite from the ground up. Especially when you're replacing a foundational technology like the display server. In the same time Microsoft reworked their display driver model twice without requiring a single change from application developers. The Linux world doesn't have that many application developers, we should not be asking them to continually chase newer and newer APIs. A rolling stone gathers no moss.
Oh no, not this again. The design of Wayland started 18 years ago, but the stabilization happened 14 years ago, and the _convincing_ across the ecosystem obviously happened way later than that.
I would put the year closer to 2016, when distros started to consider Wayland as an option.