[kouteiheika]

What security issues?

I really don't get the security angle. If I'm already running arbitrary code then it doesn't matter that Wayland is more "secure" than X11. It's just silly security theater, because there are plenty of other ways you can access whatever other applications are doing and interfere with them, even if the display server doesn't allow you to do that directly.

The only security benefit I see is if you're running sandboxed applications and you want to connect them to your display server, then sure, there is a benefit here, but how many people are running untrusted GUI apps in a sandbox on a desktop?

[sillystuff]

Even if you are sandboxing, you can do that with X. Just put the sandboxed app into a nested X server. Some sandboxing apps like firejail make it trivial to do this using xpra as the nested X server.

I wish Wayland had been more ambitious. Without a standard shared server that window managers can run on without implementing their own compositor, it is just duplication of effort, and a mess of incompatible ways of doing things; I suspect this was intentional to create a higher bar for "fragmentation", but what a mess. It will be even worse when Wayland on non-linux becomes a thing, since most WM/DEs with Wayland support are using Linux specific d-bus to work-around Wayland limitations.

[antisol]

There are real security issues with X. For example, there's not really much of a permissions system on the X protocol, which is why X tends to be configured to either deny everything but localhost or not listen on TCP at all by default.

When you allow a host to use your X display, you allow that host a crazy level of control over your system. IIUC you can do all kinds of nasty stuff with it, like getting info about other applications/windows and i think even arbitrary drawing on the screen (i.e over those other windows). You can also do stuff like snoop mouse movement and keyboard presses (i.e keylogger), and not just in your own application. As I understand, it's really pretty nasty and insecure to allow an untrusted remote machine to use your X server. It's not a good situation.

Weyland's solution does, admittedly, close this class of security issues very effectively - by just not being a remote protocol at all.

[creatonez]

> The only security benefit I see is if you're running sandboxed applications and you want to connect them to your display server

This is a mundane and common way of doing things, now that Flatpak is common and major sandboxing bugs in most popular packages have been fixed.

Also, all major web browsers already come with their own built-in sandbox for web content, and a great deal of complexity is spent outside of this sandbox making sure the process can actually print rendered page content to the Xorg screen without also being able to take over the entire Xorg server. For many years, Firefox ignored the problem and had a sandbox that doesn't prevent an RCE from keylogging Xorg. This was only fixed in Firefox 99, but like Chrome, this implementation had to be overly complex to support Xorg, so it risks introducing new attack surface. This complexity can be eliminated by Wayland and Pipewire.

[gjsman-1000]

> 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.

[troyvit]

> 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.

[antisol]

> Switching to Wayland lasts about 10 minutes though before I find some breakage that prevents me from using it.

Ugh, dammit, I'm real sad to hear that - I would have hoped it'd be more usable than that at this point - they've been working on it for so long!

[Ckirby]

[..]"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

[antisol]

>The fact that you even listed it as an "issue" with Xorg immediately disqualifies you from making any further statements on the issue

Yep.

PSA: If you think not breaking user space is an "issue", please don't ever do anything but non-critical web development.

[gjsman-1000]

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.

[yyyk]

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).

[kouteiheika]

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.

[jmclnx]

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.