Hacker News Reader

Professional pentester here - Wayland alone doesn't really do much for you, security wise. It is still very possible for an application simply running under a wayland compositor to do lots of nasty things.

The Wayland protocol provides the building blocks for someone to create an Android-like sandboxed environment, but doing so would break every application. Snaps and Flatpak come closer, but still generally miss the mark, since many applications require your entire home directory to be bind mounted in their container.

Running wayland alone gets you very little in terms of sandboxing. It locks the front door, but leaves the backdoor and all your windows open, because that's what every application under the sun expects.

> Under X11, you are basically running every application with root, always.

This is ... not true, either broadly or generally. You're saying this because Xorg runs as root, which means that any security flaw in Xorg yields root access. I think saying that "you are running every application with root" is stretching it a bit, but I'll accept it.

But Xorg doesn't have to run as root. OpenBSD started it years ago with Xenocara, but AFAIK Fedora also does not run Xorg as root. I'm not sure what other OSes are doing, but it's at least not a flaw of X11 in general, just a flaw of Xorg.

> This is ... not true, either broadly or generally

I’m saying that because if you ever type in your password, e.g. into a screenlocker, into a terminal with sudo, or an apt-get gui, every application can listen to those input events. Every application has the ability to be a keylogger by default. And with that captured password, it then can either inject input events into your terminal, or run sudo itself.

> The Wayland protocol provides the building blocks for someone to create an Android-like sandboxed environment, but doing so would break every application. Snaps and Flatpak come closer, but still generally miss the mark, since many applications require your entire home directory to be bind mounted in their container.

That’s true, but also not. With X11, even a flatpak without any special permissions or bind mounts can still basically control your system. Just listen for input events until you see the keys "s u d o", then listen until you see something that looks like a password, then wait until the user is not paying attention, and inject virtual input events to start a terminal and inject input events to run "sudo rm -rf /*" with the password you captured earlier.

By making the ability to intercept, record, or inject input events a special API, wayland at least allows flatpaks to be sandboxed at all.

> With X11, even a flatpak without any special permissions or bind mounts can still basically control your system. Just listen for input events until you see the keys "s u d o", then listen until you see something that looks like a password, then wait until the user is not paying attention, and inject virtual input events to start a terminal and inject input events to run "sudo rm -rf /*" with the password you captured earlier.

Why such complication? An hostile application can simply add an "evil" line to your .bashrc and you are fucked anyway. No need to keylog anything, nor the fancy stuff that you describe. It doesn't need to be a graphical application, even. The "ls" command can do it!

Flatpak runs applications in what’s nowadays referred to as container: the application can’t see any processes outside the container, can’t access any filesystem except for files you explicitly open with the application, and especially can’t edit your .bashrc.

That’s the point of flatpak. But as long as you use X11, there’s one single privilege escalation path left, and that’s the complicated one I described above.

What if I don't trust the person that sent me the flatpack container itself? A truly secure sandboxing should be a standard OS facility, not tied to a package distribution method. The flatpack/snap model is all wrong. I need to run arbitrary hostile applications in a safe manner, not only those that the developers have decided to distribute in a certain form.

Sure, but the flatpak model is a way to get these advantages for as large a userbase as fast as possible. If you use flatpaks without bind-home under wayland today, you’ve significantly improved your actual security already.

Sandboxing arbitrary badly behaving software is just going to use the same APIs as flatpak, so this helps for your use case as well.

> Flatpak runs applications in what’s nowadays referred to as container: the application can’t see any processes outside the container, can’t access any filesystem except for files you explicitly open with the application, and especially can’t edit your .bashrc.

That's just false. Flatpak has the ability to restrict access to such resources, but it's completely up to the author of a Flatpak application if they make use of it. Like my file manager and text editor are Flatpaks fetched from flathub.org and both applications have unrestricted access to my whole home directory by default, including my shell configuration -- even the Chromium Flatpak can do that by default.

Edit: I just counted, out of 30 installed Flatpaks from flathub.org 19 have full access to either my whole home directory or the host file system.

That's true, but not really relevant. The point of flatpak is that it can sandbox applications if just the right flag is set, but this sandboxing becomes useless on X11.

Long-term, all applications should strive to be properly sandboxed this way

> That's true, but not really relevant.

Of course it is. Someone who read your comment and didn't question it might now believe that Flatpaks would enforce filesystem sandboxing and prevent, say some game, from accessing their shell configuration or ssh keys. That's false and it's dangerous, because nothing is worse from a security perspective than misinformed users who have a false sense of security.

> but this sandboxing becomes useless on X11.

That's also false. For example X11 provides mechanisms like the X11 security extensions which prevent clients from accessing each others data through the X11 protocol (like key events or buffer content), which means when I run my color picker or xev in a such an X11 security context they literally stop working outside of their own window. Firejail makes this type of sandboxing easily accessible and it also provides the ability to easily isolate x11 clients with xpra or xephyr.

So it's not like it can't be done, it's just that Flatpak doesn't care about it -- which is fine. With dbus you get the same issues, because clients on the same bus aren't isolated from each other. In this instance however Flatpak cared and implemented a dbus proxy to isolate clients from each other without throwing dbus away.

> all applications should strive to be properly sandboxed this way

I agree, but definitely not this way! The sandboxing details must be 100% controlled by the user. The people who distribute the application should have no say whatsoever about their required permissions. That's ultimately for the user to decide. From the point of view of the application, all files are visible, but it may be a mock filesystem with mock resources. Letting the application distributors chose the permissions defeats the whole purpose of the sandboxing.

Ah, that's fair.

Still, assuming a lack of other sandboxing, running a keylogger is pretty trivial. It's not by default, as you put it, but an un-sandboxed application has enough access to your filesystem to perform tomfoolery and get your credentials. At that point, there's no need to start a terminal, you just load some shellcode in whatever process you control, and say goodbye to your data.

As for sandboxing, well, you're right, although one could sandbox X11 if they wanted to. "X-on-X" is actually a thing, rarely used outside developing X, but I could see it being used for seamless sandboxing with some work. Work that, inevitably, no-one will actually do, so there's that ;)

It actually is feasible to sandbox X11 in that way, I believe this is what security-focused distributions like Qubes and Whonix do. But yeah, it is essentially working around the problems with X11 and not really suitable for ordinary use.

To me the real progress needed is that applications need to move to using sandbox-friendly APIs so they don't break when put in the sandbox, and moving to Wayland is a key part of that. Applications built around the X11 idea of always having full access to everything will need changes regardless of what sandboxing solution is in use.

> I’m saying that because if you ever type in your password, e.g. into a screenlocker, into a terminal with sudo, or an apt-get gui, every application can listen to those input events.

And any program can (on a relatively default box) trace arbitrary programs under your gid and scan memory for passwords. The real issue here is that there are very weak process boundaries within a gid (because it is historically most convenient), not necessarily a lot wrong with X11.

Every other boundary can be restricted relatively easily. For example, flatpak already solves the issue you mention.

But the X11 boundary can’t be resolved unless you put a whole X server into every single application’s container with XonX, or you replace X11.

Which is part of why wayland exists.

Can be restricted when appropriate. Removing the ability to share resources and calling Wayland complete is what people are laughing at.

Putting holes into a solid block is a lot easier than patching something that looks like swiss cheese.

(Sorry for butchering up the quote)

Wayland’s security is not sufficient but necessary for a safe OS. (As others mentioned X-on-X can also be a sufficient solution for that)

I think the point about root is not so much about whether Xorg is run as root, but rather that any application can then elevate itself as root by listening to the key events to catch your password (for example when unlocking your screen) and then sudo with it.

> You're saying this because Xorg runs as root, which means that any security flaw in Xorg yields root access.

They're saying that because every app under Xorg can do keylogging they're effectively running as root, as any of them can keylog your root password next time you type it in.

"But Xorg doesn't have to run as root"

All the hand wringing over root privilege escalation on Linux is almost irrelevant for most single-user systems, as since there's really only one non-root account which usually has all the data the user cares about, getting access to just that non-root account would be disaster enough for the user.[1]

So if Wayland's design is standing in the way of doing useful things because they're concerned about root privilege escalation, they've got their priorities mixed up.

[1] - not to mention that once a non-root account is exploited then getting root in some other way, even if Wayland itself can't be exploited, is usually not difficult.

The goal isn’t to prevent escalation to root, but to prevent escalation out of a sandbox.

If you sandbox an application today, while it can’t access the filesystem at all, and nothing under your user account, as long as it can show you a window under X11, it can log, manipulate, and inject any input events or window contents of any other windows as well.

That’s the one single big hole in todays sandboxes under linux, and there’s only two options to solve it: put a whole separate X server into the sandbox of every single application with X-on-X, or replace X. Which is one of the things wayland fixes.

I get the frustration, but fundamentally, screen sharing and screenshots are so integral to my daily use that I couldn't even consider wayland. For nearly any remote worker at this point, at least the ones I work with, this is fundamentally true.

In 2021, screen sharing and screenshots are table stakes.

I use KDE spectacle under Gnome/Budgie for screenshots (works fine) and screen sharing works fine with Slack, Teams, Discord and Jitsi.

Screen sharing and screenshots do work on wayland as long as the application is updated to support it. Electron only recently gained this capability so not all electron apps have updated yet.

No one will fault you for using X because zoom hasn’t supported wayland yet. The problem is people sharing blatant falsehoods like “wayland doesn’t support screen sharing” when there are plenty of programs that can do just that on wayland.

> Sadly, KDE still doesn’t support it nicely under Wayland (so I moved to Ubuntu Budgie), but under X11 it’s entirely impossible to run it properly, as except for Qt nothing supports mixed DPI, or mixed refresh rates properly.

Sounds like a roughly equivalent situation either way? Personally I'd sooner use only Qt applications than have to use Gnome.

I’m using (except for firefox) 100% Qt applications under Ubuntu Budgie (which is a bit like elementary but with Wayland support).

The result is good enough for my use case, I don’t have to deal with toy applications and I can use the full crisp resolution.

And thanks to standard protocols, I can use KDE software like KDE Spectacle as screenshot tool or screensharing with Slack, Teams, Jitsi under Budgie just fine.

> I’m using (except for firefox) 100% Qt applications under Ubuntu Budgie (which is a bit like elementary but with Wayland support).

If your only non-Qt application was Firefox, what was your problem under X11? Certainly for me having to switch to Gnome's WM/panels/etc. much would be more disruptive than switching browsers. (You might find Firefox valuable enough to be worth switching your whole DE for, in which case fair enough, but I don't think it's an objective advantage for Wayland).

(IMO Konqueror is a much better browser, but I'm sure everyone has their own preferences)

I’m a dev, and as it turns out, as firefox is more standards-compliant than chrome, if something runs in firefox, it’ll pretty much run in every browser (the opposite is not true, as blink has lots of custom extensions to the standard you might use accidentally).

Plus I use firefox lockwise as password manager.

Now why does wayland break screenshot and keyboard tools? Because "every program is a keylogger by default and can see any event, look at the contents of any window" is a major security issue, especially as it means the entire security model of screen lockers or containerized applications is useless.

OK, so what's the solution here? Give up on screen-shotting tools forever? Or is there a plan to fix this somehow?

There’s an API for that. e.g. KDE Spectacle uses it, which is why it can be used as screenshot tool under wayland no matter your DE.

But by making it an explicit API, you can also apply an include/exclude list to the programs allowed to call this API, and e.g. exclude sandboxed applications from taking screenshots. Or e.g. add a permissions prompt (as on android or iOS) for an application to request to be on that include list.

I use grim[0] under Wayland, and it can grab things off my screen.

[0] https://github.com/emersion/grim

The solution is to make it a permission. On macOS you can’t just record the screen, you can open the OS settings page and tell the user to allow screen recording and now your program gains access to this feature.

This is definitely not entirely true of x11. I have mixed DPI (which, admittedly, does work for shit, but can be hacked around by using a wrapper script to launch things with different DPIs) and mixed refresh rates. The mixed refresh rates work perfectly, zero issues (as configured via nvidia drivers, admittedly annoying for other reasons).

That said I would use wayland if nvidia wasn't busy fucking everything up.

> but can be hacked around by using a wrapper script to launch things with different DPIs

I have firefox windows on both monitors, and like to drag tabs over from one to the other.

Under X11, doing so is either impossible, or requires restarting firefox, which really isn’t something I’d wanna do.

There was an old XUL extension for firefox to parse QT_SCREEN_SCALE_FACTORS and apply it instead, but that’s long gone. And normal Gtk apps never worked properly.

It's probably the mixed dpi because I've been using a Qnix overclocked to 96 Hz and a Vizio at 144 Hz, both 27" 1440p for a while and I get different refresh rates and everything works normally.

The question is then: is this isolation even useful? There are a lot of attacks that still exist when a program runs in userspace and that are not inherent to GUI programs. Example: creating an executable named sudo somewhere in a directory that is in your ~ and PATH.

Sure, but if you’re under X11, then a flatpak or any other jailed application can still trivially elevate itself to root.

Jailing applications only has a meaningful benefit whatsoever under wayland, as a flatpak without bind-home under wayland is actually properly sandboxed. Still a rare case, but at least it’s possible and getting even somewhat common.

Wayland is only one piece in the security puzzle. Flatpak and SELinux are the other pieces. Under X there is no point sandboxing a GUI app since X provides an escape.

And yet on every other OS, users can take screenshots and use virtual keyboards... It's not because X's security model is broken that the solution is 'we'll just remove that functionality'.

And yet instead of looking at sibling comments you asked the same question again, so I’ll have to answer it for at least the fifth time in this thread.

Wayland allows the same as well. It’s just an include/exclude list for such APIs, so you can actually limit which programs can access what.

Under X11, jailing GUI apps is entirely useless as there is no actual security boundary. Under wayland, you as user are in control and can define whether spectacle should be able to take screenshots (sure) and whether myflashlight-flatpak should be able to access all input events and take screenshots (probably not).