X.Org Server & XWayland Updated Due To Another Six Security Vulnerabilities

[Weasel]

This is Probono, so the technical merit of this github page is unsurprisingly lacking.

Not nearly as much as yours.

IT IS the job of the display server to make sure applications can't send arbitrary and unchecked input to other applications, and applications can't pretend to be other applications through it. This should be the default rather than "opt in".

Ok but who asked about your opinion?

It is NOT the job of the display server, but of a sandbox. Literally what he said.

You're the type of clown who also wants to force sandboxing on everything by default. Not just by default but unable to disable it. "Built-in" sandbox into everything. YOU are the one restricting choices.

It is entirely possible to make a wayland compositor that allows that, but no one will do it because its a bad idea.

If apps don't make use of it, it's pointless.

[Weasel]

As for that link, I don't know what to say, maybe they are right or maybe they are not.
But I definitely don't agree with the part about security.
In my opinion every place is good have some security limits / restrictions / control.

Security is good up until the point where it removes functionality. At that point you make it opt-in or able to be disabled. Something Wayland doesn't.

You remind me of those crap browsers who absolutely refuse "insecure" connections with no way of turning it off, even if you know what you're doing. Then you can't visit the site at all, imagine if your life depended on it. Fucking pathetic.

[ssokolow]

It is NOT the job of the display server, but of a sandbox. Literally what he said.

If the compositor isn't in charge, then your sandbox needs to be a nested/proxy compositor, similar to how GNU Screen is a full-blown terminal emulator with a complete internal model of the terminal state, which then re-renders to terminal control sequences instead of pixels. It needlessly complicates things and leaves you in a situation similar to what Windows is drifting toward, where Microsoft is exploring running Win32 on a second NT kernel inside an honest-to-God virtual machine and then exposing it to the host Win32-less Windows using a customized version of RDP to get XWayland-esque isolation because it's so hard to retrofit it with sandboxing.

The problem isn't the display server being responsible for defining an API that constrains applications, it's the developers stubbornly digging their heels in and refusing to implement a set of privileged APIs, forcing people to route around them and implement things like ydotool, which implements a subset of what xdotool did by bypassing Wayland's security model and talking straight to the Linux kernel's evdev layer so Wayland doesn't realize it's receiving software-generated input events.

[indepe]

Security is good up until the point where it removes functionality. At that point you make it opt-in or able to be disabled.

Maybe in some cases but not in general. It's too easy for hackers to make you flip the switch.

[rabcor]

Any time anyone with real skills combs through the hair of xserver a handful of bugs fall out Wayland cannot become default everywhere fast enough.

One would think it would be only wayland that has constant security vulnerabilities being discovered since it is about 30 years younger than X, but apparently sane design can take you a long way.

Is it tho? Is it sane? or is it just lazy and too lacking in substance for there to be any real bugs? I mean they keep harping on about how it's just a protocol right? So the security vulnerabilities, most of them won't be in the protocol, they'll be in stuff like wlroots, gnome and plasma instead. At least with xorg, most of these vulnerabilities are packed into X itself and not distributed among all the different environments.

[Weasel]

Maybe in some cases but not in general. It's too easy for hackers to make you flip the switch.

That's literally skill issue lol. These people are as dumb as fish hence the term "phising".

[Weasel]

If the compositor isn't in charge, then your sandbox needs to be a nested/proxy compositor, similar to how GNU Screen is a full-blown terminal emulator with a complete internal model of the terminal state, which then re-renders to terminal control sequences instead of pixels. It needlessly complicates things and leaves you in a situation similar to what Windows is drifting toward, where Microsoft is exploring running Win32 on a second NT kernel inside an honest-to-God virtual machine and then exposing it to the host Win32-less Windows using a customized version of RDP to get XWayland-esque isolation because it's so hard to retrofit it with sandboxing.

The problem isn't the display server being responsible for defining an API that constrains applications, it's the developers stubbornly digging their heels in and refusing to implement a set of privileged APIs, forcing people to route around them and implement things like ydotool, which implements a subset of what xdotool did by bypassing Wayland's security model and talking straight to the Linux kernel's evdev layer so Wayland doesn't realize it's receiving software-generated input events.

What developers are you talking about? Wayland devs? The other devs have no choice so they're forced to use stupid hacks because Wayland gives them no fucking choice.

And yes, that's the point of a sandbox in this case, to filter requests to the compositor. How else would it work? Even on Wayland where you may want to further control/sandbox some apps. Services used by sandboxed apps must go through such proxies, it's normal, otherwise any bug in said service would result in app breaking out of the sandbox. It's not specific to Wayland compositors.

For instance people complain about X11 running as "root" and saying how security exploits (which btw can exist in Wayland compositors too) can have "escalation of privilege", but tbh if I sandbox some apps like the web browser, if its privileges equal my main user, then that's already a disaster since it has access to all my files. It doesn't even have to be root. So rootless X11 or Wayland here doesn't help at all because it breaks out of the sandbox.

[varikonniemi]

Is it tho? Is it sane? or is it just lazy and too lacking in substance for there to be any real bugs? I mean they keep harping on about how it's just a protocol right? So the security vulnerabilities, most of them won't be in the protocol, they'll be in stuff like wlroots, gnome and plasma instead. At least with xorg, most of these vulnerabilities are packed into X itself and not distributed among all the different environments.

X only adds problems, the same vulnerabilities are distributed in the numerous x clients as in wayland compositors. x clients probably being worse in that regard, as x forces a really bad design onto them.

[Danny3]

Security is good up until the point where it removes functionality. At that point you make it opt-in or able to be disabled. Something Wayland doesn't.

You remind me of those crap browsers who absolutely refuse "insecure" connections with no way of turning it off, even if you know what you're doing. Then you can't visit the site at all, imagine if your life depended on it. Fucking pathetic.

I agree!
And I fucking hate it too when Firefox doesn't let me bypass a security warning, especially as you said I know what I'm doing!

[Danny3]

Last time i checked (week ago) steam still does not run on wayland so....

What are you talking about?
I've been using Wayland for 3-4 years already and of course I used Steam in all this time!
Or you are talking about native Wayland support?
Well Steam is not even 64-bit, so...
I don't think Valve cares to updated it to the latest standards as long as it works.