> how many people are running untrusted GUI apps in a sandbox on a desktop?
1. More and more every day - and that should be our goal. More sandboxed apps, not less. Otherwise, Linux on the desktop will never be as secure as a Mac (which has, objectively, the best desktop app permission systems available).
2. Xorg only does windows, with no sense of importance. What's the problem with that? For a long time, this meant that the Lock Screen was literally just a window, drawn on top of all your other windows. If anything crashed your Lock Screen, system was open for business. This has been heavily hacked and worked around, but it's still a potential threat. Some of the more "lightweight" distributions still use software that is vulnerable to this; because we've sure patched the hell out of that Lock Screen software to please not crash.
3. Keyloggers. More and more apps are using Electron - and shipping JavaScript and other code right to your device with a potentially obsolete browser engine. The last thing you want is some JavaScript shipped to your out-of-date Electron app that keylogs what you are doing on your entire desktop; simply because the developer misconfigured CORS or didn't use a pinned certificate or there was a middleman on your network or numerous other possibilities. On Xorg, that's completely theoretically possible. Combined with issue #2, where your Lock Screen is quite possibly just another window to be keylogged, and you start to see how things can escalate quickly.
4. Xorg is never just Xorg. Xorg, by itself, is almost unusable in 2023. You need extensions - over 30 of them built on top of Xorg, to result in a functional desktop. Sounds super secure. Even worse, Xorg has a mandate to never break userspace - so once an extension is shipped, it's there forever. As a result, many of these extensions aren't even used or tested, which is why Linux has, if I recall correctly, 4 Xorg extensions to handle a mouse with only one of them being used. There's also multiple abandoned joystick extensions. Again, sounds secure.
These are not the attributes, or traits, of a secure system that we should be proud of. It's embarrassing and the sign of hobbyist work.
There's also other issues at play:
1. Xorg is so obscenely complicated, and the code so bad, that the developers have openly remarked there are probably less than a dozen people who understand Xorg and can actually work on it. That doesn't sound like a very good long term plan.
2. Xorg is both the protocol and the implementation, which isn't how you want to do things. Normally, you want a standardized protocol; with multiple implementations of the protocol, so that the protocol can be easily adapted for the use case available. We did this with the internet, where HTTP is the protocol, and the various web browsers are the implementation. Imagine if Netscape was the protocol and the implementation combined. That sucks. With Wayland, Wayland is the protocol, but Mutter or KWin or others are the implementations. Some implementations are better than others, but that's OK. If you want to one day rewrite your compositor to take Wayland instructions and execute them in Rust, you "easily" can. On Xorg, you're reverse-engineering and mimicking behavior bug-for-bug the full stack downward.
3. There are upcoming technologies that may be exceedingly difficult, if not impossible, to build into Xorg. Like good 144hz support, or HDR. You might not care about them yet - but trying to shoehorn them into Xorg is a bridge too far.
> Secondly, Xorg only does windows, with no sense of importance. What's the problem with that? For a long time, this meant that the Lock Screen was literally just a window, drawn on top of all your other windows. If anything crashed your Lock Screen, system was open for business. This has been heavily hacked and worked around, but it's still a potential threat. Some of the more "lightweight" distributions still use software that is vulnerable to this; because we've sure patched the hell out of that Lock Screen software to please not crash.
I learned this years ago, although not in such detail, and it just blew my mind. You can even see it. I wake my laptop from sleep, my screen flickers and I see my desktop, then the lock screen paints over the top like a flasher closing his coat. It makes me cringe.
Switching to Wayland lasts about 10 minutes though before I find some breakage that prevents me from using it.
[..]"Even worse, Xorg has a mandate to never break userspace"[..]
Xorg is a major fundamental part of the "desktop" part of "Desktop Operating System
The fact that you even listed it as an "issue" with Xorg immediately disqualifies you from making any further statements on the issue
If you think that it's acceptable for a minor software update to break down potentially hundreds of not thousands of office workstations then you are quite frankly insane
By itself, it's not a bad thing. When we are shipping extensions for two-button mice in C with no automated testing, fuzzing, or security review, and no mouse has used those extensions in decades, and that until recently ran as root, that's a problem.
1. There were many very good reasons to get rid of X.
2. But Wayland made some very dubious choices, like 'multiple implementations' which will lead to very difficult to diagnose bugs. I strongly suspect the motivation was economical rather than technical.
3. Or the security model without adequate protocol support. Where the extensions aren't always compatible (see 2).
Okay, fair enough, you do have a point, even though practically right now it's mostly only theoretical considering how little sandboxing modern Linux does by default. I agree that we need more sandboxing, and then getting rid of X11 makes sense from a security perspective.
Not me, I use something far simpler when not on Linux, pledge and unveil. Linux snadboxing uses far more resources and diskspace that what OpenBSD is doing.
I wish OpenBSD had better video hardware support. That means I wish a specific vendor would stop being a d**k and open up their GPU.
1. More and more every day - and that should be our goal. More sandboxed apps, not less. Otherwise, Linux on the desktop will never be as secure as a Mac (which has, objectively, the best desktop app permission systems available).
2. Xorg only does windows, with no sense of importance. What's the problem with that? For a long time, this meant that the Lock Screen was literally just a window, drawn on top of all your other windows. If anything crashed your Lock Screen, system was open for business. This has been heavily hacked and worked around, but it's still a potential threat. Some of the more "lightweight" distributions still use software that is vulnerable to this; because we've sure patched the hell out of that Lock Screen software to please not crash.
3. Keyloggers. More and more apps are using Electron - and shipping JavaScript and other code right to your device with a potentially obsolete browser engine. The last thing you want is some JavaScript shipped to your out-of-date Electron app that keylogs what you are doing on your entire desktop; simply because the developer misconfigured CORS or didn't use a pinned certificate or there was a middleman on your network or numerous other possibilities. On Xorg, that's completely theoretically possible. Combined with issue #2, where your Lock Screen is quite possibly just another window to be keylogged, and you start to see how things can escalate quickly.
4. Xorg is never just Xorg. Xorg, by itself, is almost unusable in 2023. You need extensions - over 30 of them built on top of Xorg, to result in a functional desktop. Sounds super secure. Even worse, Xorg has a mandate to never break userspace - so once an extension is shipped, it's there forever. As a result, many of these extensions aren't even used or tested, which is why Linux has, if I recall correctly, 4 Xorg extensions to handle a mouse with only one of them being used. There's also multiple abandoned joystick extensions. Again, sounds secure.
These are not the attributes, or traits, of a secure system that we should be proud of. It's embarrassing and the sign of hobbyist work.
There's also other issues at play:
1. Xorg is so obscenely complicated, and the code so bad, that the developers have openly remarked there are probably less than a dozen people who understand Xorg and can actually work on it. That doesn't sound like a very good long term plan.
2. Xorg is both the protocol and the implementation, which isn't how you want to do things. Normally, you want a standardized protocol; with multiple implementations of the protocol, so that the protocol can be easily adapted for the use case available. We did this with the internet, where HTTP is the protocol, and the various web browsers are the implementation. Imagine if Netscape was the protocol and the implementation combined. That sucks. With Wayland, Wayland is the protocol, but Mutter or KWin or others are the implementations. Some implementations are better than others, but that's OK. If you want to one day rewrite your compositor to take Wayland instructions and execute them in Rust, you "easily" can. On Xorg, you're reverse-engineering and mimicking behavior bug-for-bug the full stack downward.
3. There are upcoming technologies that may be exceedingly difficult, if not impossible, to build into Xorg. Like good 144hz support, or HDR. You might not care about them yet - but trying to shoehorn them into Xorg is a bridge too far.