I know I'm missing something... but I also suspect it's the sort of something that's worth missing.
I know I'm missing something... but I also suspect it's the sort of something that's worth missing.
Desktop linux doesn't have this sway.
Which is a security hole along with being able to read keystrokes meant for any app, grabbing pixels that aren't yours, etc... the features people complained were missing from Wayland for the longest time were often security issues that X could never solve by design. But hey, fuck security I want to run Xeyes!
This means 99.9% of actual threats to your security remain the same.
If you want actual isolation you need to run something like qubes which ironically actuality uses X
Unfortunately most linux distros and users do not take security seriously unless it's in a server environment. Desktop linux is awfully far behind systems like MacOS.
This is a doomer mindset that ignores the advances the rest of the industry has been making. There is a big difference from malware having to find a 0day in order to cause harm to the user and malware developers being able to do exactly what they want without even a permission dialog box showing up.
I won’t debate whether that’s true (it probably is, given that “not compromising your data or credentials” is close to a tautology “if you don’t let your stuff get stolen, it won’t get stolen”), but focus on
> This means 99.9% of actual threats to your security remain the same.
I don’t see how that follows because we’re not living in “traditionally” anymore.
IMHO, if iOS and Android had run “traditional X Windows”, the number of successful over the air attacks would be way higher or nobody would use smartphones out of fear of getting hacked.
Honest question: why does this matter? If you end up with running malware as your user haven't you already "lost" in any of a wide variety of ways that Wayland does nothing against?
Or is it that Wayland is trying to bring the mobile security model to the desktop with partially untrusted apps?
The security benefits of wayland are useful when you're also using other things like namespaces/seccomp (with bubblewrap/flatpak), and pipewire which I believe has a similar access control mechanism.
>Or is it that Wayland is trying to bring the mobile security model to the desktop with partially untrusted apps?
I trust my programs, but they can have bugs when parsing untrusted content. (ffmpeg, browsers). Although I've never been hacked, I'd like my systems to have defenses against this (without going full mobile security mode and giving up functionality and user freedom, or running everything in inconvenient isolated boxes with VMs).
Also, I'm not sure if I'd trust proprietary games, so preventing them from doing naive things (I don't expect them to exploit kernel vulns) like snooping on files by using namespaces is nice.
But the Linux ecosystem builds up to things bit by bit. So in this case, Wayland is progress towards a goal where untrusted apps can be run and are limited in what they can do by design. It doesn't matter at the moment, but one day it'll be an important brick in a secure system.
That isn't a mobile security model. It's a good and more modern security model. Desktop operating systems are moving this way too but it's harder due to apps not originally being designed for it.
No. Your web browser does a pretty good job of not storing your login info (if you tell it not to) locally. Under X, malware can monitor everything you do and log your credentials. Under Wayland it can not. Simple as that.
Malware will still try to exploit bugs and CVEs to get access, but finding a hole in a wall is entirely different than not having a wall in the first place. Holes can be patched.
People run untrusted code on their machines every day. Most of it is in the browser (which has walls) and is written by advertisers that are not well scrutinized by the sites people visit. Then there is the whole trend of containers which put more walls around native apps.
So in your question, replace malware" with "untrusted code" and it becomes more realistic.
Anyway to echo beanjuiceII's point, number of times I've been pwned by an X keylogger: Zero.
(That you know of). Number of times I've been pwned by any technical vector (that I know of): zero. The fact it hasn't happened to you does not imply that defending against it is pointless. Early in my computing career I used the same weak password for everything. Never had an account takeover. That does not imply that using different secure passwords for each site is pointless.
The number of ways I might have been pwned and not known about it is basically infinite. Why should I prioritize replacing X11 over any other hypothetical threat for which I have no evidence that I'm at particular risk of? Nobody has photographed my house keys and made copies that I know of. Should I re-key all my locks just to be extra safe? I could replace my front door with an armored door too.. but a burglar would just come in through a window instead so what would be the point?
There's no point armoring your front door unless you also put bars on all your windows, and there's no point adopting wayland for security unless you fix all the other security problems with running malicious software on the GNU/Linux desktop too. And miss me with the QubesOS/flatpack/etc suggestions, my days of playing amateur sysadmin are over I just want to use my computer, not tinker with experimental desktop administration.
That's not true either. The malware would require privilege escalation to co-opt my browser. Even if you weren't wrong about that, I don't know why you complain about both weak security models AND a very big improvement in Linux security (Wayland).
Oh right, on X the malware could just wait for me to type in my password for something I wanted to do and grab it. then it could sudo just like me.
Does it? Sure it can't replace /usr/bin/firefox, but what's stopping the malware from writing a fake shortcut to ~/.local/share/applications/malwarefirefox.desktop and waiting until you click the fake shortcut? Or kill the running firefox and start the malware version? Or add some malware extension directly to ~/.mozilla/firefox/profiles? Or something else?
Or are you assuming the malware is running in a sandbox like AppArmor?
Ummm right. The point wasn't that Xeyes is a security threat. It's that Xeyes is only possible because X is insecure by design, which is what allows the eyes to literally monitor what you're doing. Mouse, keystroke, screen grab. Hey go ahead and do your online banking with X. Just remember the real malware is headless, not literally displaying eyes to let you know it's watching.
Clearly, something is missing here. Why not a permission system like browsers do? A little popup that asks "X is requesting access to your full screen" rather than this "convenience VS security" black and white view most people seem to take a stance at?
Discord capturing the screen is a valid use case, but it should be approved by the DE and it should be possible to block this request.
Currently the mainstream DEs just approve the request by default but in the future I can see a permissions dialog asking the user if they want to allow access to screen recording, and maybe a small icon in the top bar to show when recordings are happening.
This idea that screenshots require special OS-level privileges has been tested and, in practice, does not work. Literally nobody wants compositor-specific screenshot applications. It should have been addressed in the Wayland standards in the early drafts.
Fair enough unrestricted access to any pixel is a security problem. But banning all access to pixels other programs control was an unworkable position that, in hindsight, didn't work. Telling people that the process that merges all the pixels together needs special OS-level support for reporting on what the merged output look like is just not sane. Something went wrong in the design process.
IMHO the right answer might be a GUI toolkit (out of process) that has an API for system resources. Permission would be either granted by the user (a file dialog already indicates what files an app should have access to) or set at the application level at install time. The failure to develop solutions like this is why browsers have taken it on by themselves, because they are constantly running untrusted code.
https://gitlab.freedesktop.org/wayland/wayland-protocols
They're figuring out how to extend Wayland to something usable that supports screenshots. Anything that supports plain Wayland is going to be crippled by the protocol limitations, but anything implementing a selection of the extension protocols will be useful.
You can see the docs in pretty form here: https://wayland.app/protocols/
Only took 15 years. Pay special attention to the name of Drew DeVault who has been one of the major heros in the story. The Wayland devs apart from Drew do deserve serious kudos, moving away from X was never going to be easy. But copying pixels into a shared buffer as some sort of challenge is just hard to overlook.
Dude please. Wayland has been 100 percent usable FOR ME for years. Plain Wayland is not "crippled" for MY use case. It may be crippled for YOUR use case, and that's a legitimate concern, but don't broad brush Wayland as not usable and crippled in general. For many of us it's already where it needs to be. That said, I do hope those remaining things get sorted out soon.
The de-facto Wayland standard is not going to be the core protocol, in the same way that the core X protocol is woefully insufficient [0] for actually running a modern linux system. It needs extensions. The core protocol just isn't featureful enough - as has been clearly demonstrated by a decade lost in the woods not supporting basic desktop functionality. If a design goal was to delay adoption by 10-15 years while they think about things then I suppose it could be considered a success. Other systems have managed to move much faster than that without doing much harm.
The sticking point is that at least the core X protocol didn't need a decade of R&D for a screenshot extension [1]. I suppose people could claim with a straight face that screenshots and streaming are unforeseen use cases, but they would be excellent poker players. It was a design mistake not to explicitly address that up front. An honest one, made by very competent people, but nevertheless a mis-step.
[0] https://wiki.gnome.org/GraphicsRequirements
[1] I'll admit this is before my time - maybe it did? But the X protocol is a hot mess and Wayland is inching towards the point where it's release is closer to the birth of X windows than the present day.
Agreed. What's the missing feature? Screen sharing? Remote sessions? Overlapping displays (doesn't work in Android BTW)? We've had all of these for years.
Even fractional scaling on hiDPI monitors has been good enough for me to not care for at least 5 years.
It's like systemd; the people bitching either want to sound contrarian or actually know enough to roll their own down to the low level. At which point I must say; show me the code. Open a PR or give it a rest
My last-resolved reason not to switch: Popular compositors didn't support scaling for XWayland on par with how it works when X11 controls the screen right up until this year.
This meant that you either had to opt out of scaling in Wayland (horrible on high dpi displays) or accept super blurry XWayland windows.
Of course, it would be great if we didn't need XWayland but... That's not going to happen until more users have Wayland desktops and users like me weren't about to accept Wayland desktops while this type of problem existed.
[1] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
On top of that, in the wider PC system, hardware routinely launches without dev/test in the Linux world. Drivers often work for a whole chipset, so may often be running a specific device within that chipset that was never tested or seen by the developer of the driver at all, let alone in the hardware combination.
(And the Linux environment and the Android environment in ChromeOS are already using Wayland.)
A sibling comment also mentioned hardware. There's certainly a lot less driver and hardware variance as well.
When it comes to chromeOS, I think they are switching to a wayland compositor, and it'll be a lot easier for them because there they control everything.