Isn't only the transport layer of X insecure? That could be swapped out with another layer. With Wayland you have to use VNC which is fine for local networks, but not for remote ones.
Plus the attack angle is someone having permission to execute apps on your machine, there's plenty of other nasty things they could do.
Oh, yes, it's very likely that Wayland will end up with the exact same vulnerabilities. It's very hard in fact to design a windowing system that allows rich interaction between apps, but still maintains per user access control (never mind actually implementing it).
No, the attack angle is either a untrusted app running in a sandbox (fatpak, snap or crosvm or qemu with wayland passtrough[1]) with only a connection to the compositor or a trusted app running in a sandbox getting exploited, any apps handling foreign data is suspect here (Web browser, mail client, pdf, office suite, etc.).
[1] https://lore.kernel.org/qemu-devel/20231005024330.836-1-gurc...
That's a huge win. Firefox is a mainstream product with a ton of attention. And I get it from upstream repositories, it's not something I'm compiling myself.
If I can get away with giving 2-3 apps total on my computer screen recording permissions (OBS, Firefox, maybe a screenshot tool or an accessibility client), that is a massive reduction in attack surface, that would be a very large security win.
It would be great if the primary attack vector for recording my screen was an application with decades of sandboxing efforts going into preventing untrusted code from doing things like recording my screen without my knowledge.
I genuinely don't understand the issue, it's a big security win if I can close off permissions on my system and have them open just for the apps that have good sandboxing around their untrusted code. Bonus points if the app in question allows per-domain screen recording permissions, which Firefox does.
I would go so far as to say that (one of) the reasons you run 99+% of your untrusted application code in Firefox is probably because Firefox is one of the very few places on your computer where it's safe to run that code. So it's a big win if we can start pulling some of those same sandboxing ideas into the native world; maybe that makes it easier to use more native apps for some tasks. It's a big win if I can treat apps on my computer the same way that I treat a random website.
Also keep in mind that "untrusted" is not a binary state. I pretty much only run apps on my computer that I "trust", but do they need to be able to record my screen? No, and I love the possibility of not needing to worry quite as much about what happens if they get compromised.
----
There's a somewhat strange notion here that because people do everything in the browser per-app privileges don't matter. But in fact, the reason the browser's security model works and the desktop's doesn't is because the browser has per-domain privileges and permissions, and it's not that per-app permissions don't matter, it's that they do matter and the lack of them is why we centralize untrusted code into one of the few apps on our computers that has per-"app" permissions. Browser permissions work because they are granular, you can grant Zoom access to record your desktop without granting access to Facebook.
So maybe if the desktop copies that, maybe far in the future you won't need to run everything in your web browser just to feel secure. But as it stands with X11 I feel a lot more comfortable using a browser to record my screen specifically because it has privileges and permissions around that are segmented per-domain/"app". The lack of sensible security controls on the desktop is a contributing factor to why people don't use the desktop, and being able to lock that in and restrict the scope of where screen recording can happen does make me feel a lot more secure about my desktop.
Agreed. This debate is particularly frustrating because X11 vulnerabilities get brought up as an excuse for ignoring other sandboxing efforts, and then Wayland gets dismissed because of vulnerabilities when not using other sandboxing methods. You can't win!
----
Even if I'm giving my web browser full access to my computer, there are apps I want to sandbox without running them in a full VM. And there are multiple parts to this puzzle to get better security and sandboxing, but those sandboxing efforts don't work if I can't secure the most basic parts of the visual desktop. If someone is demanding perfect sandboxing before we start looking at X11, they're going to be waiting a long time because there is a limit to how much progress we can make in this area while X11 stays dominant.
And okay, sure, we're setting up clipboard access for web browsers, but I can turn that off. And then I can take advantage of flatpak, snap, qemu, whatever and I can at least get closer to actual sandboxing controls, even for non-malicious apps. And I can do partial sandboxing, which is also a good thing -- the idea that everything needs to be either fully separated from each other or have full permissions is just not a good approach to security, sometimes we partially trust things.
----
Linux security is like we're in a boat with multiple holes that are taking in water, and whenever anybody tries to plug one of the holes, critics jump out and say, "what's the point, if someone can execute apps on your machine, there's plenty of other nasty things they could do." And so you move to the other hole and somebody says, "what's the point, attackers can just record your desktop." There are multiple holes on the ship, let's start patching them.
Getting better sandboxing controls into Linux is something that is going to take time and that means we're going to be patching holes while other holes exist that we haven't gotten around to yet. There is a limit to what tools like Bubblewrap can do for a graphical app if it's hooked up to X11. And yeah, I want clipboard controls for my web browser, but also I run more apps on my computer than just a web browser, and different apps have different problems. It's not even just about exploits or malicious apps entirely, sandboxing is useful even just for setting up temporary builds or dealing with buggy code and the fact that we don't have perfect solutions shouldn't be an excuse to not improve the situation at all.
In practice, that's true (things like flatpack claim to support fake sandboxing, but whatever.)
Hypothetically, in a universe where Wayland was running on top of something other than the Linux desktop ecosystem, you could run untrusted code from bash with su, and have it talk to wayland directly, and it'd be OK. Today, you have to run it in a web browser, or using a VM with display virtualization drivers, or use any of a dozen other sandbox choices.
Those all managed to get the correct security properties under X11 because they're properly modularized. Wayland isn't, so to get this one feature, they're expecting all software to be rewritten.
ALL software was ALREADY rewritten for the web, so just use a web browser running directly on the hardware instead of bothering with X11 or Wayland or some hypothetical replacement like X12. That's just an extra useless layer that nobody needs.
A web browser is totally extensible and scriptable in JavaScript and WASM. Standards based. Excellent networking support. Streaming video. Secure sandboxing. Remote accelerated 2D and 3D graphics and GPU programming and WASM engine. Not rocket science. Off-the-shelf, well tested, open standards based solution. Problem already solved.
Why this is not the most obvious thing in the world since the Effrafax painted a mountain pink, and hasn't already been done, totally baffles me. It's as if the Linux community would much rather bicker and squabble about X11 -vs- Wayland for another 30 years than solve the problem once and for all and permanently and perfectly.
https://en.wikipedia.org/wiki/Somebody_else%27s_problem
>An SEP is something we can't see, or don't see, or our brain doesn't let us see, because we think that it's somebody else's problem. That’s what SEP means. Somebody Else’s Problem. The brain just edits it out, it's like a blind spot.
>The Somebody Else's Problem field... relies on people's natural predisposition not to see anything they don't want to, weren't expecting, or can't explain. If Effrafax had painted the mountain pink and erected a cheap and simple Somebody Else’s Problem field on it, then people would have walked past the mountain, round it, even over it, and simply never have noticed that the thing was there.
https://news.ycombinator.com/item?id=38442601
https://news.ycombinator.com/item?id=38442660
https://news.ycombinator.com/item?id=38445174
https://news.ycombinator.com/item?id=31988890
https://news.ycombinator.com/item?id=29094938
https://news.ycombinator.com/item?id=29097030
https://news.ycombinator.com/item?id=20182294
If I have to live on your world, I'll probably just chuck it all in and work with my hands for a living instead.
I think their comment means you’d be better off targeting an OS level sandbox (maybe based on OCI(?), which means a different container for each OS kernel or breaking kernel change — new docker doesn’t run on old linux as it is).
If you chose the OS level sandbox correctly, that would probably be more cpu-efficient than the web browser.
However, that’s a big “if”, since most of the linux sandbox thingies take multiple seconds to spawn a process, and multiply memory usage by 10-100x.
X11 sucks. Wayland sucks. Get rid of them both! But the browser's not going away, and it's open standards based and cross platform, and there's a huge amount of collaborative work and money and talent going into making it better and more powerful and more efficient and more secure across the entire industry and all platforms, unlike X11 and Wayland (which nobody gives a shit about outside of a few fanatical Linux desktop users), or even the Windows and Mac desktops and Android and iOS interfaces (which billions of people use every day, but are stagnant terribly designed dead-ends).
The browser is a sandbox, so why run it on top of another leaky inflexible insufficient outdated sandbox full of clumps of dehydrated urine and cat turds like X11 or Wayland, instead of directly on the hardware?
No modern desktop environment is complete without a browser, so since you're stuck with it, why not just use the browser itself as the desktop environment (or whatever user interface paradigm you choose to use), since you're never getting rid of the browser, and modern non-browser desktops aren't as flexible or powerful or extensible as a browser, and most useful applications have been ported to run in the web browser environment anyway, so they can run across many different platforms, and be easily distributed and efficiently used over the network (unlike Wayland or "modern" X11 apps).
I'm just surprised this seems to be so hard for some people to understand, in spite of the fact that I've been making the same argument for more than a decade, and provided many links to those arguments, because it seems extremely obvious and straightforward to me, and the technology is finally mature enough to pull it off.
> No modern desktop environment is complete without a browser, so since you're stuck with it, why not just use the browser itself as the desktop environment..?
Because I want to use my desktop environment as my desktop environment. I've invested time and energy optimising it for my workflow and I'd like to continue to benefit from using it.
> non-browser desktops aren't as flexible or powerful or extensible as a browser
Again, I don't know what this means. My desktop is literally programmable. As in, I can edit and recompile the source code directly. Please tell me what's more powerful than that.
> they can run across many different platforms,...
I only need my apps to run on one platform
> ...and be easily distributed and efficiently used over the network (unlike Wayland or "modern" X11 apps).
`apt install my-x11-app my-wayland-app` `#include <sys/socket.h>`
> However, that’s a big “if”, since most of the linux sandbox thingies take multiple seconds to spawn a process, and multiply memory usage by 10-100x.
And this is the thing I'm not willing to accept. Well, I can tolerate excessive memory consumption depending on what I'm doing, but I refuse to entertain long boot times. It's the main reason I avoid Java apps, Flatpacks, and so on.
Did you read any of them? Did you read my other explanation below that I just wrote personally for your benefit? Does it make any sense to you?
Do you understand what I mean now, or do you need me to give you some more citations of other times I've written the same thing, because there are more. What was unclear, and did I leave anything out?
Do you have any more questions I haven't answered time and again and already gave you links to but you just didn't bother reading?
It's exasperating and insulting that you blithely dismiss what I wrote without saying what you disagree with or can't understand, but I promise you, it really is easy to understand and extremely obvious on its face, if you will just take the time to read what I wrote, before complaining you don't know what it means.
If you have time to complain, then you have time to read what I wrote and linked to, before complaining you don't know what it means.
If you're too busy to read, then please don't waste your and my time complaining you don't understand what you didn't bother to read.
My experience with making an app work consistently across browsers is that it's hard work. Making it also work consistently with each OS it runs on is considerably harder. You want to guess how many times I've been asked to even consider either of those two things by a manager, let alone make them a priority? Never.
And going by my experience as a user of browser-based software, I'd say that's pretty normal across the industry.
And that's to say nothing of the fact that these apps are typically slow, cumbersome (by which I mean they throttle my CPU and drain my laptop battery), and crash no less frequently than unsafe apps written in unsafe languages like C (despite the fact that that's supposed to be impossible).
It seems to me that you want to rewrite the world in the browser. That doesn't seem very different to me from rewriting the world in Wayland. Whatever the differences between the two, they are insignificant besides the fallacy of rewriting the world.
As for the rest of your reply, I have no idea why you think I owe you however much time it would take me to read however many links you posted above. If you have something relevant to say, say it in the thread. Don't presume to leave it for me as a homework assignment.
And I haven't actually used it[0] but I thought waypipe was the better option for remoting?
[0] Well, successfully or recently; I'm assuming it's usable now.
You speak as if application sandboxing within the ever existed in the past... Not that people tried to build it and X doesn't play well with it.
I guess then the claim is more that no common implementation is amenable to sandboxing, and the compatibility break of a brand new protocol means they can implement it from day 1 in the way they like. Which is a lot weaker an argument, but practically speaking, it's true that no one is rushing to bolt on security features to X. To be clear I'm not realy a Wayland fan.
In other words: while not originally UNIX-y, X matured in an ecosystem that idiomatically treats every userspace program as a perfect proxy for the user agent themselves. Sandboxing is a foreign (but good!) idiom that’s being bolted onto that paradigm.
$ ps ax -ouser,args | awk 'NR==1;/X.*:/'
USER COMMAND
_x11 /usr/X11R6/bin/X :0 vt05 -auth /etc/X11/xenodm/authdir/authfiles/A:0-PFzcIG (Xorg)
root X: [priv] (Xorg)