There's Rapid Progress Being Made On KDE For Wayland

[dragorth]

How's Wayland in preventing apps from spying on each other like preventing one app from seeing your keyboard input to another app?

Does that have anything to do with Wayland? Isn't Waylaan just a compositing manager for blits to the screen? Why would wayland have control of keyboard messages. That would be LibInput libraries job, wouldn't it? Or Weston, the Window manager implemention of Wayland?

[DoctorWho]

Does that have anything to do with Wayland? Isn't Waylaan just a compositing manager for blits to the screen? Why would wayland have control of keyboard messages. That would be LibInput libraries job, wouldn't it? Or Weston, the Window manager implemention of Wayland?

I should have said the Wayland/Weston system. With X it's a problem that one app can see another app's input. Not sure what part of X or it's libraries are responsible for this security failure.

[Nobu]

I think I found a way on KDE to switch between HDMI and headset output easily, but maybe not...I know I had been just switching the priorities in system settings.
On gnome-shell, there's a useful extension that lets you change the output device from the volume control applet--handy, that. lol

[Ericg]

I should have said the Wayland/Weston system. With X it's a problem that one app can see another app's input. Not sure what part of X or it's libraries are responsible for this security failure.

Its a failing of the entire X model, not just one thing in particular.

Wayland makes taking screenshots of your applications much harder, since applications can't just read eachother's graphics buffers. But the keylogger issue a bit harder... see my next post.

[Ericg]

Does that have anything to do with Wayland? Isn't Waylaan just a compositing manager for blits to the screen? Why would wayland have control of keyboard messages. That would be LibInput libraries job, wouldn't it? Or Weston, the Window manager implemention of Wayland?

What he's referring to is the fact that under X all buffers are public (making it easy to create a screen recorder) and any application can capture all input (making it easy to create a keylogger)

Wayland makes the first one -much- harder because it assumes all applications are untrusted and more-or-less hostile, unlike X which basically trusts all applications.

The latter one is a much harder problem to fix.. See: https://github.com/MaartenBaert/Wayland-keylogger

I don't know if the Wayland developers ever found a way around that issue. Regardless the problem isn't actually theirs, the problem is with the kernel and the entire security model of modern desktops without sandboxing. The keylogger takes advantage of LD_PRELOAD to inject itself into other processes and thus steal their keystrokes, it then autostarts itself on login by adding itself to ~/.profile.

The problem here is that most modern operating systems start programs with the same security context as the user that started them. If User "Eric" opens Firefox then Firefox has Eric's security context. If Eric can modify his own files then Firefox, started by Eric, can modify Eric's files, including ~/.profile.

The only way to stop that is 1) SELinux or 2) Sandbox everything. I just did a quick "ls -laZ" and most of my files are tagged user_home_t, including my ~/.bash_* files, which means SELinux (right now) wouldn't stop this kind of attack. SELinux policy COULD be modified to try and prevent this, but it doesn't right now.

Sandboxing is probably the best way to prevent this kind of attack, or any other attack. GNOME and Red Hat are pushing for Sandboxed applications but there's a few problems there that are still getting worked through. The big one is that the sandbox has to be opt-in otherwise it will break older, un-updated applications-- which means malicious applications can just not-opt-in and continue on their merry way. That's where SELinux could stop in and be a second line of defense-- but again, a policy would have to be written.

[teldar]

How's Wayland in preventing apps from spying on each other like preventing one app from seeing your keyboard input to another app?

It's actually the role of the compositor (Weston) to properly route the inputs to the concerned process attached to the current active window. One difference exposed by other is that it would be indeed difficult to make a screenshot app that's not part of the compositor. And that's normal you actually need to have some knowledge of the vsync and when the frame is finished to actually know when to read the pixels to avoid tearing. I speak from experience since I did that for my game, which is kind of a simplified compositor.

[doom_Oo7]

If Eric can modify his own files then Firefox, started by Eric, can modify Eric's files, including ~/.profile.

In one hand, yes, this is a security failure, in the other hand a small reason why I left windows for linux is because not being able to write to Program Files & al. in recent versions was driving me mad to no end. Even just having to do a manual confirmation in a dialog pisses me off.

[anda_skoa]

you cannot change per-application volumes from the docker, only from the settings menu.

I use KMix, just like on Plasma 1.

Cheers,
_

[anda_skoa]

The keylogger takes advantage of LD_PRELOAD to inject itself into other processes and thus steal their keystrokes, it then autostarts itself on login by adding itself to ~/.profile.

While this is one attack vector, it isn't even necessary on X11, because any client can get the events from the X server (which is the process reading from the input device).
A Wayland compositor is not supposed to do allow that so "spying" on another client becomes more difficult (preload, attaching via a debugger, etc).

So the security benefit is not about being "impossible", but moving away from "trivial".

Cheers,
_

[kreijack]

The keylogger takes advantage of LD_PRELOAD to inject itself into other processes and thus steal their keystrokes, it then autostarts itself on login by adding itself to ~/.profile.

If you can use LD_PRELOAD to inject into other processes you have the control of other processes: mouse event, key press, files read, and also the screen... This a bigger security hole than X.
I think that the security benefit of wayland are somewhat excessively valued: if you are executing a "non trusted" process, you are always in trouble. I am more worried for the flexibility which we would lost: I am thinking about the screen shot application and/or the color picker...