7 ms·

I think it was the "security" argument. Some magic words like "security" and "protect the children" make most people go insane, abandon all reason.

by M95D 27d ago

dralley 27d ago
Xorg's security (and X11 in general) is objectively terrible - this is not even a debatable question.
- wing-_-nuts 27d ago
  Great, so let wayland be a hardened option for those who care.
  - mort96 27d ago
    It is and you're free to use X if you want
    - nazgulsenpai 27d ago
      IMO the issue is that the same group stewarding Wayland was also xorg, and intentionally stifled improvement on xorg even when the work just a matter of merging the PR.
      - dralley 27d ago
        >and intentionally stifled improvement on xorg Open source developers are not required to spend their time prioritizing your priorities. You just have to look to Xlibre to see that a lot of contributions are quite bad quality, and in a C codebase of Xorg's complexity and security profile it's not a small job to review things.
        nazgulsenpai 27d ago
        Nothing I said in any way implied that freedesktop should be required to do anything. I can't speak to the quality of xlibre merges, only that if whatever is going on over there led to improvements in xorg after a drought, that's a good thing.
      - mort96 27d ago
        Merging a PR by drive-by contributors is far from trivial. As the maintainer, you become responsible for the other person's code for all eternity; it's on you to read it, understand it, update it when stuff around it changes, and fix it when it breaks. Not a problem for obviously-correct changes of a couple of lines, but most PRs aren't like that.
        nazgulsenpai 27d ago
        I understand and that's a fair point. I should have phrased that differently, in that the PRs for features were waiting to be merged. I'm sure merging into a codebase as... storied? as xorg is no small task.
    - wing-_-nuts 27d ago
      If wayland had been sold as a hardened display for those who needed that level of security, I would not have a problem with it. As it is, the community got constantly browbeat with 'this is the future' and 'it's so much faster!' when recent benchmarks have proven that to be false.
      - mort96 27d ago
        Then go use X. Nobody's stopping you, you can just ignore any brow beating. /ignore is a useful IRC command. You'll probably find it to be a not great experience, since almost all the people who spend their time actually working on graphics and GUIs in the Linux world prefer to work on Wayland. So X doesn't get much love these days (and you're not entitled to their efforts after all). But it's not like they erased all the old X code from existence.
        normie3000 27d ago
        > You'll probably find it to be a not great experience I'm confused where I'm likely to be suffering. If I start using Wayland tomorrow would I even notice? Apart from having to switch DEs, of course.
        mort96 27d ago
        Depends on a lot of context. You may notice issues with some GPU drivers if you have hardware with new drivers, because older GPU drivers contain X-specific workarounds which new drivers may lack (I know this is an issue with the Apple M1 GPU, I suspect it might be an issue with Panthor as well). But that's not really relevant with typical consumer hardware. Desktop environments have varying levels of X support these days. GNOME hasn't been adding new features to X for a while, and GNOME 50 completely drops X. So if you're a GNOME fan you may not like that. KDE ends X11 support in 6.8. But it's always possible to stay on GNOME 49 or KDE Plasma 6.7 forever, or use an X11 window manager. The X11 back-end is deprecated in GTK 4, so don't expect a ton of improvements to it, but it'll remain supported for all of GTK 4's life so you probably won't notice anything there immediately. But it means GTK 5 will drop the X11 back-end entirely, so at some point in the coming decade, GTK applications will gradually stop working. Regardless of GUI toolkit, applications are slowly moving towards the XDG Portal way of doing things instead of the X11 way; which is fine, there's no reason why X systems can't support the portal dbus APIs, but I suspect that there will be more issues there once applications start dropping their X11 implementations of things. This is an area under active development and I would expect X11 to not see much of that development. I have no idea if anyone has implemented a portal for X11. Maybe you'd have to do that yourself eventually to keep new versions of certain programs running, I don't know how the state of portals is on X. There are other things too that software can do to break X11 support even when their toolkit supports X, and expect that this has started happening to some degree and will slowly continue.
- M95D 27d ago
  It is, but my argument is that better security is not needed! There is only one user. All apps are his/hers. Linux security inside a user's session is bad in general. It all started in the '90s from the principle that all installed software is FOSS, sources inspected, and compiled distro packages trusted. - Permissions are per-user, not per-app. If I ever need permissions to something, every app I run gets the same permissions. - No isolation for personal files. Any app running as me can read all of them. Bookmarks, firefox passwords, everything. - No per-app firewall mechanisms. Any app can call home and send user's files, including those passwords. - System events are broadcasted via dbus to any app wanting to listen to them. So why make the GUI secure if everything else isn't? If anyone wants to have better security (or privacy) in Linux, would have to start with the basic permissions model.
  - zbentley 26d ago
    It’s not about multi-user security. I would not like a compromised video player to be able to see my Signal chats just because both apps are in the same window system.
    - M95D 26d ago
      Does Signal save history? Or does it save your encryption keys in a file? If it does, then a compromized program can just read those files directly. No need for X, no need for a GUI, a simple console app can do it. More, a compromized app can execute Signal itself, attach a debugger to it, fake inputs, read outputs, read it's memory, etc. and impersonate you. Also without X.
      - zbentley 25d ago
        > Does Signal save history? Or does it save your encryption keys in a file? Even on Signal Desktop, retrieving things from an outside app is very-hard-to-impossible depending on configuration and what you're after. There's a reason most Signal bots (even benign ones) hook up an event stream to a specially configured Signal daemon and build an external record of data from Signal by watching for events over time. > More, a compromized app can execute Signal itself, attach a debugger to it, fake inputs, read outputs, read it's memory... I think you're missing a lot of the attack surface here. "Local execution is game over" is a technically-true-but-incomplete thought-terminating statement; it's more useful to assess "if I grant local execution, what attackers are likely to be interested in that, and what attacks are they likely to perform?" Like sure, if you install something containing a full userland rootkit designed to attack a given application, and that application isn't running in a container such that you have to pivot through root to access it, you're screwed. Those do exist, but there are a ton of local attack vectors that aren't that. Many pieces of malicious code that install with local apps aren't that complex, since complexity begets size and suspicious-behavior detection. Less complex malware would prefer to e.g. read Firefox's sqlite database files rather than try to execute new instances of trusted programs like Signal to get data out of them. We know from analysis of a lot of malware that it overwhelmingly prefers low-hanging fruit that's easy to harvest quickly and without doing much that risks detection. Some malware's scarier, but like Mickens said, most people a) aren't gonna get Mossad'd on, and b) can't do much about it if they are: https://www.usenix.org/system/files/1401_08-12_mickens.pdf https://www.usenix.org/system/files/1401_08-12_mickens.pdf There are also local attack vectors that don't involve installing malware directly. Local programs that run code (browsers) and plenty of other exploits in e.g. decoders are limited enough in what's possible within the exploit chain that they can't calc.exe you and instead rely on info harvesting from speculative execution Flatpak/Snap/etc., also can assist with a layer of local-app security here. Put all that together, and you end up at the conclusion that a large volume of data is only practically accessible to a lot of malware by accessing another running app's memory. Two significant ways to do that are 1) reading memory directly (significantly mitigated by hardware permissioning/segmentation/ASLR) and 2) reading data those apps publish to the display system. Wayland makes that second one a lot harder.
- ElectroBuffoon 27d ago
  Yet Qubes OS demostrates it's possible to run X11 programs isolated from each other. They had the need and will to improve security, and found the way over a decade ago. Making server side decorations an important part of it. Oh, the irony.
  - throwaway84932 27d ago
    Qubes OS achieves isolation by separating apps into VMs. Wayland does this at the display protocol level. If Qubes OS is serious about security, they should consider Wayland with containerization. It would result in a similar level of isolation with significantly lower resource overhead.
    - zbentley 26d ago
      I feel like the sheer volume of OS LPEs and escape CVEs in container runtimes indicates that, at least for now, the security boundary capabilities of containers are inferior to those of VMs. Which is ironic, given that a lot of the tools that underly a container runtime were originally designed to facilitate security, not ease of deployment.
      - throwaway84932 26d ago
        You're aware of the VM escape issues over the past decade? There's no perfect, and high overhead from running many guests can also create security risks. Wayland with all of its problems remains a logical step forward from the X model.
        zbentley 26d ago
        I was narrowly responding to the point about Qubes using VMs. I have no problems with Wayland’s design; I agree that it’s a step forward.
        throwaway84932 26d ago
- account42 26d ago
  It's better than the security of pretty much anything physical in your home. Somehow you seem to be OK with your stove letting anyone turn it on and have other solutions to deal with misuse. The same solutions apply to your virtual desktop.
wing-_-nuts 27d ago
You'll excuse me if I am not terribly enthusiastic about breaking all sorts of functionality to solve a security problem I've never experienced in my 25 years on linux.
- ToyKeeper 27d ago
  Exactly. It's hard to be enthusiastic about something which breaks a lot of stuff I rely on daily, when the benefit is that it fixes problems I've never had. My theory about the motivation behind the extra security is that it's largely driven by corporations wanting to make desktop Linux less free and less open, and normalize proprietary software instead of open-source. Because profit. Proprietary software is inherently not trustworthy, so the execution environment needs extra security and restrictions, and must be generally less powerful to reduce the damage it can do. Essentially, proprietary software needs the same precautions as malware. So the corps needed to "androidify" desktop Linux. Hence the change from curated distro package repositories to corporate app stores, and the reason why there's so much money pushing to replace X11 with Wayland. In an open-source ecosystem, users and developers are one and the same, or at least on the same "side", cooperating with each other to make tools which work as well as possible for everyone. Each big program tends to be a collaborative effort where a lot of people contribute to make things better for everyone. Things mostly "just work" and people can typically trust their computers not to do anything weird or hostile. Very different than a proprietary commercial ecosystem, where users and developers have more of an adversarial relationship. Each program tends to be created in a closed silo by one person or a relatively small team, and is designed primarily to extract money from users, with all other concerns being secondary. It is very common for profit-driven developers to engage in deceptive practices, or do things the user doesn't want, like showing advertisements, collecting and selling data, sabotaging products from competitors, using the device as a node in a botnet or secret compute farm, forcing unwanted updates, microtransactions or subscription fees, etc. So nothing can be trusted, and the entire system needs extensive protections against every type of misbehavior imaginable... even if that means reducing the power and features available to the user. I've really enjoyed the past few decades of living entirely in the open-source world, where those problems pretty much just don't exist. But with corps pushing the androidification of desktop Linux, I fear those days may be coming to an end.
preisschild 27d ago
Are you seriously acting like every application having full access over other applications is not an actual security issue?
- M95D 27d ago
  It is, but nothing can be done about it. That's how Linux permissions work. Any app running as me can execute any other app I have permissions to run. It can pipe stdin/out/err, trace it, etc. Why should the desktop apps be different? See my other comment too.
  - zbentley 26d ago
    My desktop apps can’t trace other apps because they don’t have my sudo password. Some of my desktop apps run in containers/snaps or whatnot and other user processes can’t get to their internals without pivoting to root. Apps can’t read each other’s memory because of segmentation. There is a lot more to desktop inter-app security than “if an app had a root shell then it could compromise things”. A great many attack vectors that we see constantly have a much narrower ingress than that.
    - M95D 26d ago
      You don't need sudo for trace under the same account. You can even attach a debugger and read all app's memory. Virtualization is another thing entirely. But if you want it that way, then why not simply start a second X for the untrusted app?
- simonra 27d ago
  It is for netflix, or the cloud image storage provider that wants to secure against the consumer easily extracting data and going to someone else. The user being able to easily take a program made by a third party and have it completely rearrange the guts of any other program is the basis of consumer security in a world without a unified government keeping commercial interests at bay.
- account42 26d ago
account42 26d ago
Yeah people never stop to ask "security from whom". I don't need my display servers to secure me from the tools I choose to run.

I think it was the "security" argument. Some magic words like "security" and "protect the children" make most people go insane, abandon all reason.

by M95D 27d ago

I think it was the "security" argument. Some magic words like "security" and "protect the children" make most people go insane, abandon all reason.

dralley 27d ago

Xorg's security (and X11 in general) is objectively terrible - this is not even a debatable question.

wing-_-nuts 27d ago
Great, so let wayland be a hardened option for those who care.
- mort96 27d ago
  It is and you're free to use X if you want
  - nazgulsenpai 27d ago
    IMO the issue is that the same group stewarding Wayland was also xorg, and intentionally stifled improvement on xorg even when the work just a matter of merging the PR.
    - dralley 27d ago
      >and intentionally stifled improvement on xorg Open source developers are not required to spend their time prioritizing your priorities. You just have to look to Xlibre to see that a lot of contributions are quite bad quality, and in a C codebase of Xorg's complexity and security profile it's not a small job to review things.
      - nazgulsenpai 27d ago
        Nothing I said in any way implied that freedesktop should be required to do anything. I can't speak to the quality of xlibre merges, only that if whatever is going on over there led to improvements in xorg after a drought, that's a good thing.
    - mort96 27d ago
      Merging a PR by drive-by contributors is far from trivial. As the maintainer, you become responsible for the other person's code for all eternity; it's on you to read it, understand it, update it when stuff around it changes, and fix it when it breaks. Not a problem for obviously-correct changes of a couple of lines, but most PRs aren't like that.
      - nazgulsenpai 27d ago
        I understand and that's a fair point. I should have phrased that differently, in that the PRs for features were waiting to be merged. I'm sure merging into a codebase as... storied? as xorg is no small task.
  - wing-_-nuts 27d ago
    If wayland had been sold as a hardened display for those who needed that level of security, I would not have a problem with it. As it is, the community got constantly browbeat with 'this is the future' and 'it's so much faster!' when recent benchmarks have proven that to be false.
    - mort96 27d ago
      Then go use X. Nobody's stopping you, you can just ignore any brow beating. /ignore is a useful IRC command. You'll probably find it to be a not great experience, since almost all the people who spend their time actually working on graphics and GUIs in the Linux world prefer to work on Wayland. So X doesn't get much love these days (and you're not entitled to their efforts after all). But it's not like they erased all the old X code from existence.
      - normie3000 27d ago
        > You'll probably find it to be a not great experience I'm confused where I'm likely to be suffering. If I start using Wayland tomorrow would I even notice? Apart from having to switch DEs, of course.
        mort96 27d ago
        Depends on a lot of context. You may notice issues with some GPU drivers if you have hardware with new drivers, because older GPU drivers contain X-specific workarounds which new drivers may lack (I know this is an issue with the Apple M1 GPU, I suspect it might be an issue with Panthor as well). But that's not really relevant with typical consumer hardware. Desktop environments have varying levels of X support these days. GNOME hasn't been adding new features to X for a while, and GNOME 50 completely drops X. So if you're a GNOME fan you may not like that. KDE ends X11 support in 6.8. But it's always possible to stay on GNOME 49 or KDE Plasma 6.7 forever, or use an X11 window manager. The X11 back-end is deprecated in GTK 4, so don't expect a ton of improvements to it, but it'll remain supported for all of GTK 4's life so you probably won't notice anything there immediately. But it means GTK 5 will drop the X11 back-end entirely, so at some point in the coming decade, GTK applications will gradually stop working. Regardless of GUI toolkit, applications are slowly moving towards the XDG Portal way of doing things instead of the X11 way; which is fine, there's no reason why X systems can't support the portal dbus APIs, but I suspect that there will be more issues there once applications start dropping their X11 implementations of things. This is an area under active development and I would expect X11 to not see much of that development. I have no idea if anyone has implemented a portal for X11. Maybe you'd have to do that yourself eventually to keep new versions of certain programs running, I don't know how the state of portals is on X. There are other things too that software can do to break X11 support even when their toolkit supports X, and expect that this has started happening to some degree and will slowly continue.
M95D 27d ago
It is, but my argument is that better security is not needed! There is only one user. All apps are his/hers. Linux security inside a user's session is bad in general. It all started in the '90s from the principle that all installed software is FOSS, sources inspected, and compiled distro packages trusted. - Permissions are per-user, not per-app. If I ever need permissions to something, every app I run gets the same permissions. - No isolation for personal files. Any app running as me can read all of them. Bookmarks, firefox passwords, everything. - No per-app firewall mechanisms. Any app can call home and send user's files, including those passwords. - System events are broadcasted via dbus to any app wanting to listen to them. So why make the GUI secure if everything else isn't? If anyone wants to have better security (or privacy) in Linux, would have to start with the basic permissions model.
- zbentley 26d ago
  It’s not about multi-user security. I would not like a compromised video player to be able to see my Signal chats just because both apps are in the same window system.
  - M95D 26d ago
    Does Signal save history? Or does it save your encryption keys in a file? If it does, then a compromized program can just read those files directly. No need for X, no need for a GUI, a simple console app can do it. More, a compromized app can execute Signal itself, attach a debugger to it, fake inputs, read outputs, read it's memory, etc. and impersonate you. Also without X.
    - zbentley 25d ago
      > Does Signal save history? Or does it save your encryption keys in a file? Even on Signal Desktop, retrieving things from an outside app is very-hard-to-impossible depending on configuration and what you're after. There's a reason most Signal bots (even benign ones) hook up an event stream to a specially configured Signal daemon and build an external record of data from Signal by watching for events over time. > More, a compromized app can execute Signal itself, attach a debugger to it, fake inputs, read outputs, read it's memory... I think you're missing a lot of the attack surface here. "Local execution is game over" is a technically-true-but-incomplete thought-terminating statement; it's more useful to assess "if I grant local execution, what attackers are likely to be interested in that, and what attacks are they likely to perform?" Like sure, if you install something containing a full userland rootkit designed to attack a given application, and that application isn't running in a container such that you have to pivot through root to access it, you're screwed. Those do exist, but there are a ton of local attack vectors that aren't that. Many pieces of malicious code that install with local apps aren't that complex, since complexity begets size and suspicious-behavior detection. Less complex malware would prefer to e.g. read Firefox's sqlite database files rather than try to execute new instances of trusted programs like Signal to get data out of them. We know from analysis of a lot of malware that it overwhelmingly prefers low-hanging fruit that's easy to harvest quickly and without doing much that risks detection. Some malware's scarier, but like Mickens said, most people a) aren't gonna get Mossad'd on, and b) can't do much about it if they are: https://www.usenix.org/system/files/1401_08-12_mickens.pdf https://www.usenix.org/system/files/1401_08-12_mickens.pdf There are also local attack vectors that don't involve installing malware directly. Local programs that run code (browsers) and plenty of other exploits in e.g. decoders are limited enough in what's possible within the exploit chain that they can't calc.exe you and instead rely on info harvesting from speculative execution Flatpak/Snap/etc., also can assist with a layer of local-app security here. Put all that together, and you end up at the conclusion that a large volume of data is only practically accessible to a lot of malware by accessing another running app's memory. Two significant ways to do that are 1) reading memory directly (significantly mitigated by hardware permissioning/segmentation/ASLR) and 2) reading data those apps publish to the display system. Wayland makes that second one a lot harder.
ElectroBuffoon 27d ago
Yet Qubes OS demostrates it's possible to run X11 programs isolated from each other. They had the need and will to improve security, and found the way over a decade ago. Making server side decorations an important part of it. Oh, the irony.
- throwaway84932 27d ago
  Qubes OS achieves isolation by separating apps into VMs. Wayland does this at the display protocol level. If Qubes OS is serious about security, they should consider Wayland with containerization. It would result in a similar level of isolation with significantly lower resource overhead.
  - zbentley 26d ago
    I feel like the sheer volume of OS LPEs and escape CVEs in container runtimes indicates that, at least for now, the security boundary capabilities of containers are inferior to those of VMs. Which is ironic, given that a lot of the tools that underly a container runtime were originally designed to facilitate security, not ease of deployment.
    - throwaway84932 26d ago
      You're aware of the VM escape issues over the past decade? There's no perfect, and high overhead from running many guests can also create security risks. Wayland with all of its problems remains a logical step forward from the X model.
      - zbentley 26d ago
        I was narrowly responding to the point about Qubes using VMs. I have no problems with Wayland’s design; I agree that it’s a step forward.
        throwaway84932 26d ago
account42 26d ago
It's better than the security of pretty much anything physical in your home. Somehow you seem to be OK with your stove letting anyone turn it on and have other solutions to deal with misuse. The same solutions apply to your virtual desktop.

wing-_-nuts 27d ago

You'll excuse me if I am not terribly enthusiastic about breaking all sorts of functionality to solve a security problem I've never experienced in my 25 years on linux.

ToyKeeper 27d ago
Exactly. It's hard to be enthusiastic about something which breaks a lot of stuff I rely on daily, when the benefit is that it fixes problems I've never had. My theory about the motivation behind the extra security is that it's largely driven by corporations wanting to make desktop Linux less free and less open, and normalize proprietary software instead of open-source. Because profit. Proprietary software is inherently not trustworthy, so the execution environment needs extra security and restrictions, and must be generally less powerful to reduce the damage it can do. Essentially, proprietary software needs the same precautions as malware. So the corps needed to "androidify" desktop Linux. Hence the change from curated distro package repositories to corporate app stores, and the reason why there's so much money pushing to replace X11 with Wayland. In an open-source ecosystem, users and developers are one and the same, or at least on the same "side", cooperating with each other to make tools which work as well as possible for everyone. Each big program tends to be a collaborative effort where a lot of people contribute to make things better for everyone. Things mostly "just work" and people can typically trust their computers not to do anything weird or hostile. Very different than a proprietary commercial ecosystem, where users and developers have more of an adversarial relationship. Each program tends to be created in a closed silo by one person or a relatively small team, and is designed primarily to extract money from users, with all other concerns being secondary. It is very common for profit-driven developers to engage in deceptive practices, or do things the user doesn't want, like showing advertisements, collecting and selling data, sabotaging products from competitors, using the device as a node in a botnet or secret compute farm, forcing unwanted updates, microtransactions or subscription fees, etc. So nothing can be trusted, and the entire system needs extensive protections against every type of misbehavior imaginable... even if that means reducing the power and features available to the user. I've really enjoyed the past few decades of living entirely in the open-source world, where those problems pretty much just don't exist. But with corps pushing the androidification of desktop Linux, I fear those days may be coming to an end.

preisschild 27d ago

Are you seriously acting like every application having full access over other applications is not an actual security issue?

M95D 27d ago
It is, but nothing can be done about it. That's how Linux permissions work. Any app running as me can execute any other app I have permissions to run. It can pipe stdin/out/err, trace it, etc. Why should the desktop apps be different? See my other comment too.
- zbentley 26d ago
  My desktop apps can’t trace other apps because they don’t have my sudo password. Some of my desktop apps run in containers/snaps or whatnot and other user processes can’t get to their internals without pivoting to root. Apps can’t read each other’s memory because of segmentation. There is a lot more to desktop inter-app security than “if an app had a root shell then it could compromise things”. A great many attack vectors that we see constantly have a much narrower ingress than that.
  - M95D 26d ago
    You don't need sudo for trace under the same account. You can even attach a debugger and read all app's memory. Virtualization is another thing entirely. But if you want it that way, then why not simply start a second X for the untrusted app?
simonra 27d ago
It is for netflix, or the cloud image storage provider that wants to secure against the consumer easily extracting data and going to someone else. The user being able to easily take a program made by a third party and have it completely rearrange the guts of any other program is the basis of consumer security in a world without a unified government keeping commercial interests at bay.
account42 26d ago

account42 26d ago

Yeah people never stop to ask "security from whom". I don't need my display servers to secure me from the tools I choose to run.