6 ms·

Good to know this exists, so I can keep using what's been rock solid for me for the last decade for the foreseeable future.

amelius 2y ago
X has security issues. For example, an application that has access to your display can do stuff with other applications. For an interesting discussion, see: http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html http://theinvisiblethings.blogspot.com/2011/04/linux-securit...
- phendrenad2 2y ago
  Well, that's unfortunate. Someone should fix that. Is anyone maintaining X11, or is there continuation fork?
- welterde 2y ago
  There seems to be XACE/XSELinux, which seemingly exists in the mainline Xorg distro now. I wonder how the experience is with that? In practice I think it doesn't see any adoption, since most people don't run with SELinux or even AppArmor on their desktop and none of the applications run isolated from each other, so it doesn't matter that they all have full access to the X11 server. And for actual security there is qubes, which solves both the application isolation and the X11 security issue.
  - nolist_policy 2y ago
    Eh even if you secure the X11 API itself, your isolated app (browsers absolutely sandbox and isolate themselves from the rest of the system) will still share memory and have a socket open to an 33 year old c codebase (XOrg).
    - welterde 2y ago
      Not sure having shared memory and socket open to N fresh and under active feature development c codebases is that much more conducive to security? (N since while many compositors use wlroots there is still enough rope to hang yourself). To be fair, unless there is a exploitable bug in wlroots/lower wayland code, the blast-radius will be a lot more limited than if one is found in Xserver. I think the Qubes approach is the only one worth considering if one deeply cares about security.
- jasonjayr 2y ago
  Yes. That's often really useful, for remote operation, and screen shots/recording/sharing. On Windows, one app can send events to another window too.
- enriquto 2y ago
  > an application that has access to your display can do stuff with other applications. Well, of course, that's the whole point of using "applications", isn't it? To change the state of your data! Regardless of x11/wayland, the application "vim" can read (and change!) all files in my home dir. Do you also consider that a security issue? If you want to run some weird application that you don't trust, you should run it inside a container. But that has nothing to do with display systems.
  - samus 2y ago
    It kind of is, and it doesn't really have to do with an application not being trustworthy. It's a defense in depth approach against app that become compromised through exploiting bugs with security implications. The attack surface of Vim is admittedly small, but the browser is a much bigger target. I want my browser to download files, upload files that I provide, and various other things on an allow list, but not more. IDEs, the tools invoked by them, and their build artifacts should have access to the project assets and not much more. There are certainly applications that require more privileges, but I'm sure we can come up with ways to restrict them as well. The problem is that it's quite late to retrofit it onto desktop Linux. Containers are not designed to be security boundaries. They isolate their contents from the host system, but not primarily because of security. They can be used for security, but certainly not with default settings.
    - enriquto 2y ago
      > Containers are not designed to be security boundaries. So you'd prefer your graphics system to act as a security boundary? Seems very weird to me. Containers are clearly the right tool for this job, for they can run as well for non-graphical programs.
      - nolist_policy 2y ago
        The graphics system absolutely is a part of the security boundary. You can pass through your X11 or Wayland server socket in the container to run graphical applications. This is more of less what a Flatpack is.
- superdisk 2y ago
  In my mind, if you're running potentially-compromised code on your machine, you're already hosed and the display server isn't going to protect you.
  - bobmcnamara 2y ago
    Ah the binary secure/unsecure straw man.
  - orangeboats 2y ago
    Not really. You can run potentially-compromised code in a sandbox. X11 is unsandboxable though since X11 programs can see each other freely through the display server.
    - hedora 2y ago
      It’s been under a month since Linux patched a zero-day that made it trivial for any program to get root.
      - orangeboats 2y ago
        I don't see how this is related to the topic at hand. A zero-day attack can be patched, but the security issues with X11 are intrinsic to the protocol itself and are nontrivial to fix.
        welterde 2y ago
        That is not true. There are extensions to the X11 server that can resolve many of the security issues, but almost no one cares enough to use them. If you are doing X11 forwarding via SSH it defaults to a more restricted configuration that only allows a more restricted access to the server (no direct sniffing of the input devices for instance).
      - nextaccountic 2y ago
        Do you browse the internet with scripts on? (Javascript and Wasm). It is fully untrusted code that runs in a sandbox. Do you expect that random webpages are ableto steal all data from all applications you run, and all files you have? Including passwords etc.
- panzi 2y ago
  How can you implement accessibility tools without that feature?
  - nolist_policy 2y ago
    By using other, more secure interfaces like uinput, or libei[1] whose access you can allow it deny separately from the Wayland socket itself. [1] https://gitlab.freedesktop.org/libinput/libei https://gitlab.freedesktop.org/libinput/libei
    - yjftsjthsd-h 2y ago
      Those only let you blindly emulate input events, they don't let you inspect, select, or control windows.
      - nolist_policy 2y ago
        Ah for that you want to use the at-spi2 interface. This gets you access to the accessibility tree so you can not only discover and interact with windows, but also individual elements within like buttons, text fields, etc.
- bobmcnamara 2y ago
  X has support issues. For years support for anything other than XRGB8888 and siblings has been bit rotting away. A few years ago I brought up X on a Y2 display. Ended up implementing RGB888->Y2 blue noise dithering in the driver when I realized how much work native Y2 would be.
  - adrian_b 2y ago
    There is at least a decade since I have been using only 10-bit color monitors and I have never seen any problem in X with them. I do not know whether you count this as a "sibling" of XRGB8888. The only software that had problems were various installers for some professional programs, which were written in Java and which crashed immediately on 10-bit color displays. However that was a Java problem, not an X11 problem, because the same installers also crashed on Windows when the display was configured in the 10-bit color mode. Of course the color management in X is not good, but I have not heard yet about significant improvements in Wayland. In my opinion, the only right way to handle color would have been for all user applications to work only in a linear wide gamut FP16 RGB color space, like Rec. 2020. Only the display driver should be aware of the characteristics of the display, like color primaries, gamma, HDR, color resolution or pixel encoding, which should be used for an output conversion in the GPU. AFAIK, Wayland has also missed the opportunity to make such radical changes.
    - bobmcnamara 2y ago
      Java: portable bugs. I forgot about 10bit. I should have said indexed-mode or non-true-color. I meant anything below RGB888. Linear for processing would be nice where that conversion can be done efficiently, and where the display driver can make a passable representation. The system I worked on only had black, light grey, dark grey, and white. What was nice about X was that the driver could express its limitations to clients, so that the client could make smart rendering decisions and handle dithering vs not dithering appropriately, rather than doing it at the display driver layer.
    - bitwize 2y ago
      There's another problem: the pels in an X pixmap can be 32 bits wide, max. So while ten bits per color plane is feasible, any more is not. Looks like we're gonna have to devise a whole 'nother display protocol to accommodate larger pixel sizes... unless...
- fulafel 2y ago
  This post is by Joanna Rutkowska of the Qubes project (a VM based isolation system) and doesn't contain any comments in favour of Wayland. In fact I think Qubes still uses X11. Are there any writeups that make a case for how Wayland could be used to implement robust GUI isolation?
- simion314 2y ago
  >X has security issues. And Wayland is just a protocol, I would rather trust some old X11 code that was shared by entire Desktop Linux then GNOME devs code, this is my personal opinion and I will not bring forward sourced/evidence why I do not trust GNOME devs and designers.
  - bitwize 2y ago
    In the UNIX-HATERS Handbook you will see takedowns of the argument that "X is just a protocol" :)
- Ferret7446 2y ago
  Many of those security issues are features that enable users of X to do their work. Yet Wayland supporters keeping trying to convince them to switch because of those "issues". This is why Wayland adoption is slow.

amelius 2y ago

X has security issues. For example, an application that has access to your display can do stuff with other applications. For an interesting discussion, see: http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html http://theinvisiblethings.blogspot.com/2011/04/linux-securit...

phendrenad2 2y ago
Well, that's unfortunate. Someone should fix that. Is anyone maintaining X11, or is there continuation fork?
welterde 2y ago
There seems to be XACE/XSELinux, which seemingly exists in the mainline Xorg distro now. I wonder how the experience is with that? In practice I think it doesn't see any adoption, since most people don't run with SELinux or even AppArmor on their desktop and none of the applications run isolated from each other, so it doesn't matter that they all have full access to the X11 server. And for actual security there is qubes, which solves both the application isolation and the X11 security issue.
- nolist_policy 2y ago
  Eh even if you secure the X11 API itself, your isolated app (browsers absolutely sandbox and isolate themselves from the rest of the system) will still share memory and have a socket open to an 33 year old c codebase (XOrg).
  - welterde 2y ago
    Not sure having shared memory and socket open to N fresh and under active feature development c codebases is that much more conducive to security? (N since while many compositors use wlroots there is still enough rope to hang yourself). To be fair, unless there is a exploitable bug in wlroots/lower wayland code, the blast-radius will be a lot more limited than if one is found in Xserver. I think the Qubes approach is the only one worth considering if one deeply cares about security.
jasonjayr 2y ago
Yes. That's often really useful, for remote operation, and screen shots/recording/sharing. On Windows, one app can send events to another window too.
enriquto 2y ago
> an application that has access to your display can do stuff with other applications. Well, of course, that's the whole point of using "applications", isn't it? To change the state of your data! Regardless of x11/wayland, the application "vim" can read (and change!) all files in my home dir. Do you also consider that a security issue? If you want to run some weird application that you don't trust, you should run it inside a container. But that has nothing to do with display systems.
- samus 2y ago
  It kind of is, and it doesn't really have to do with an application not being trustworthy. It's a defense in depth approach against app that become compromised through exploiting bugs with security implications. The attack surface of Vim is admittedly small, but the browser is a much bigger target. I want my browser to download files, upload files that I provide, and various other things on an allow list, but not more. IDEs, the tools invoked by them, and their build artifacts should have access to the project assets and not much more. There are certainly applications that require more privileges, but I'm sure we can come up with ways to restrict them as well. The problem is that it's quite late to retrofit it onto desktop Linux. Containers are not designed to be security boundaries. They isolate their contents from the host system, but not primarily because of security. They can be used for security, but certainly not with default settings.
  - enriquto 2y ago
    > Containers are not designed to be security boundaries. So you'd prefer your graphics system to act as a security boundary? Seems very weird to me. Containers are clearly the right tool for this job, for they can run as well for non-graphical programs.
    - nolist_policy 2y ago
      The graphics system absolutely is a part of the security boundary. You can pass through your X11 or Wayland server socket in the container to run graphical applications. This is more of less what a Flatpack is.
superdisk 2y ago
In my mind, if you're running potentially-compromised code on your machine, you're already hosed and the display server isn't going to protect you.
- bobmcnamara 2y ago
  Ah the binary secure/unsecure straw man.
- orangeboats 2y ago
  Not really. You can run potentially-compromised code in a sandbox. X11 is unsandboxable though since X11 programs can see each other freely through the display server.
  - hedora 2y ago
    It’s been under a month since Linux patched a zero-day that made it trivial for any program to get root.
    - orangeboats 2y ago
      I don't see how this is related to the topic at hand. A zero-day attack can be patched, but the security issues with X11 are intrinsic to the protocol itself and are nontrivial to fix.
      - welterde 2y ago
        That is not true. There are extensions to the X11 server that can resolve many of the security issues, but almost no one cares enough to use them. If you are doing X11 forwarding via SSH it defaults to a more restricted configuration that only allows a more restricted access to the server (no direct sniffing of the input devices for instance).
    - nextaccountic 2y ago
      Do you browse the internet with scripts on? (Javascript and Wasm). It is fully untrusted code that runs in a sandbox. Do you expect that random webpages are ableto steal all data from all applications you run, and all files you have? Including passwords etc.
panzi 2y ago
How can you implement accessibility tools without that feature?
- nolist_policy 2y ago
  By using other, more secure interfaces like uinput, or libei[1] whose access you can allow it deny separately from the Wayland socket itself. [1] https://gitlab.freedesktop.org/libinput/libei https://gitlab.freedesktop.org/libinput/libei
  - yjftsjthsd-h 2y ago
    Those only let you blindly emulate input events, they don't let you inspect, select, or control windows.
    - nolist_policy 2y ago
      Ah for that you want to use the at-spi2 interface. This gets you access to the accessibility tree so you can not only discover and interact with windows, but also individual elements within like buttons, text fields, etc.
bobmcnamara 2y ago
X has support issues. For years support for anything other than XRGB8888 and siblings has been bit rotting away. A few years ago I brought up X on a Y2 display. Ended up implementing RGB888->Y2 blue noise dithering in the driver when I realized how much work native Y2 would be.
- adrian_b 2y ago
  There is at least a decade since I have been using only 10-bit color monitors and I have never seen any problem in X with them. I do not know whether you count this as a "sibling" of XRGB8888. The only software that had problems were various installers for some professional programs, which were written in Java and which crashed immediately on 10-bit color displays. However that was a Java problem, not an X11 problem, because the same installers also crashed on Windows when the display was configured in the 10-bit color mode. Of course the color management in X is not good, but I have not heard yet about significant improvements in Wayland. In my opinion, the only right way to handle color would have been for all user applications to work only in a linear wide gamut FP16 RGB color space, like Rec. 2020. Only the display driver should be aware of the characteristics of the display, like color primaries, gamma, HDR, color resolution or pixel encoding, which should be used for an output conversion in the GPU. AFAIK, Wayland has also missed the opportunity to make such radical changes.
  - bobmcnamara 2y ago
    Java: portable bugs. I forgot about 10bit. I should have said indexed-mode or non-true-color. I meant anything below RGB888. Linear for processing would be nice where that conversion can be done efficiently, and where the display driver can make a passable representation. The system I worked on only had black, light grey, dark grey, and white. What was nice about X was that the driver could express its limitations to clients, so that the client could make smart rendering decisions and handle dithering vs not dithering appropriately, rather than doing it at the display driver layer.
  - bitwize 2y ago
    There's another problem: the pels in an X pixmap can be 32 bits wide, max. So while ten bits per color plane is feasible, any more is not. Looks like we're gonna have to devise a whole 'nother display protocol to accommodate larger pixel sizes... unless...
fulafel 2y ago
This post is by Joanna Rutkowska of the Qubes project (a VM based isolation system) and doesn't contain any comments in favour of Wayland. In fact I think Qubes still uses X11. Are there any writeups that make a case for how Wayland could be used to implement robust GUI isolation?
simion314 2y ago
>X has security issues. And Wayland is just a protocol, I would rather trust some old X11 code that was shared by entire Desktop Linux then GNOME devs code, this is my personal opinion and I will not bring forward sourced/evidence why I do not trust GNOME devs and designers.
- bitwize 2y ago
  In the UNIX-HATERS Handbook you will see takedowns of the argument that "X is just a protocol" :)
Ferret7446 2y ago
Many of those security issues are features that enable users of X to do their work. Yet Wayland supporters keeping trying to convince them to switch because of those "issues". This is why Wayland adoption is slow.