AMD Radeon Linux Gaming Performance At Parity Between KDE Plasma 6.0 X11 vs. Wayland

[oiaohm]

Wayland has no user authentication mechanism (X11 uses a cryptographic cookie), the Wayland display server and the application need to be either the same user, the same user group, or the display server needs to run as root and the socket made world r/w.

No it does not

sudo su firefoxuser
firefox

$
Redone for wayland following

setfacl -m firefoxuser:r-x -$XDG_RUNTIME_DIR
setfacl -m firefoxuser:rwx -- $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY
setfacl -m firefoxuser:rw -- $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY.lock
sudo -E su -whitelist-environment=WAYLAND_DISPLAY,XDG_RUNTIME_DIR firefoxuser
firefox

This has not made the socket of Wayland world r/w.

X11 the socket accepts/rejects on authenticated users, its basically username/password authentication,

This is server interpreted. This has the X11 socket world wide writable. This means you can do exploit before the X11 server is fast enough to disconnect you as a non authorized user like the magic cookie buffer overflow one on effected servers. This is the reason why I opened bug against xserver to get them to use POSIX ACLs so this kind of attack cannot be done.

Hopefully one day it will not matter if you are using Wayland or X11 what user can access your display server will be enforced by POSIX ACL as in the OS kernel.

Do note posix ACL have been on Linux/BSD/Unix system for over 20 years now. It was over 10 years point mSparks was quoting. User asking Wayland compoistor default to be world wide writable of course the answer should be no this is insecure. Having socket world wide writable has been proven insecure by X11 CVE history of bugs that worked before the server interpreted can successfully disconnect the socket.

mSparks if not safe to have server side interpreted permissions what do you do. That right what wayland does start up locked down and force the user to use the host OS permissions to open the socket up. With ACL the socket can be opened up 1 user at a time.

Security design moves on X11 security design is stuck pre POSIX ACL and I am trying with a bug I have opened to bring it up to date.

[mSparks]

mSparks if not safe to have server side interpreted permissions what do you do.

Well, you wanted more evidence that wayland risks randsomware and malware, that single sentence 100% does the job.

[oiaohm]

Well, you wanted more evidence that wayland risks randsomware and malware, that single sentence 100% does the job.

This is not evidence. Repeated CVE against x.org X11 server says that server side interpreted permissions is not safe that evidence. I wrote if when I should have wrote are.

[mSparks]

This is not evidence. Repeated CVE against x.org X11 server says that server side interpreted permissions is not safe that evidence. I wrote if when I should have wrote are.

Maybe I'm just missing an example
When else is not having any server side interpreted permissions a thing.
ROFL.

[oiaohm]

When else is not having any server side interpreted permissions a thing.

Really when it not using the OS provided security come a thing and we should have grown out of it.

https://gitlab.freedesktop.org/xorg/xserver/-/issues/1665

This is the bug I am working on at the moment mSparks. Just look at the excuses. Solaris, Linux, BSD, MacOS and Windows will require different implemtmentations claim the reality I know for sure that Linux BSD and MacOS have the same set of functions for controlling POSIX ACL.

mSparks remember server side interpreted permissions for Local user/group is duplicating functionality your OS Kernel already provides. It does not make sense to be reinventing the wheel without valid need. Reinventing wheel without valid need equals larger more exploitable attack surface.

There is difference between server side interpreted permissions and server side managed permissions. A design with server side managed permissions has the code to set the host OS permissions to keep attack surface small. Interpreted has the server exposing itself while it works out if party should be allowed in or not..

If you were putting up the complain that Wayland suxs because Wayland protocol/design does not have any support for server side managed permissions I would not be disagreeing with you. That missing does not mean you cannot run applications as different users just makes doing it harder because you have to set the host permissions up manually. Not providing managed permission interface means it more likely for user to mess it up. Asking wayland protocol to have managed permissions is not asking wayland to provide world wide writable socket.

Please also remember X11 protocol every security thing is a extension that you can in fact opt out of.

Yes the core developers X11 xserver admits in that bug that reason why X11 x.org server socket is world wide write-able was to work around a limitation systems use to have. Not limitation they currently do have. This is why 40 years of security with X11 x.org is garbage. Lot of ways they are 20+ years in the past and need to catch up with current day.

ACL on Unix and Unix like(linux/bsd/macos...) systems have been common since 2002. Windows everything NT based has ACLs. For desktop users that would be Windows XP and newer.

Also the problem here they fix Posix ACLs that they work. People might come back and say we want application group granularity inside X11 x.org implemented.

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264

Like we are having here in Wayland for window placement.

X11 x.org need a lot of work on attack surface reduction. There is a lot of low hanging fruit like implement Posix ACL support on the socket.

mSparks we have 20+ years of excuses why they have not implemented ACL support in x.org X11 server. At some point this comes they have had no interest in making the X11 security right.

[mSparks]

Really when it not using the OS provided security come a thing and we should have grown out of it.

Seems Olivier explained it perfectly to you

"This is how Xwayland rootless on demand works."

so there is another example of why you should just uninstall it. What benefit is there to wasting your time on it?

And, btw, pretty sure wayland is the only server I have ever come across that doesn't have server interpreted permissions.

X11 x.org need a lot of work on attack surface reduction.

Putting aside that being completely off topic, that it will be decades before wayland can offer similar assurances to X11 and it for sure being no more true than any other userspace linux application.

It's still quite an interesting statement.

Are you familier with the changes that have been made to androids permission system over the last few years? Really very good. In fact both macos and android have finally actually gotten file permissions right imho. Effort there would have been lovely.

But no, all hands on deck to break everything to offer "almost identical" at subpar peformance.

Time to pivot to a better direction tbh.

[oiaohm]

And, btw, pretty sure wayland is the only server I have ever come across that doesn't have server interpreted permissions.

This is a very big catch. If everyone in a class said 2+2=5 would not make that magically correct right.

Look at your servers. How of those servers are using protocols predating POSIX ACL being common so were working around historic limitation? That covers a lot. Working around the historic limitation of only have Unix Permissions with no ACLs

Next how many do those server interpreted permissions are used for more than just if a user can access or not? With X11 protocol only XACE is deeper than user can just access the server and XACE is basically unworkable to most end users because of it dependency on mandatory access control. If the item is only to prevent incorrect local users from accessing you server this should be host permission system enforcing.

By the way Android does not give Surfaceflinger(android compositor) a world wide writable socket.

Android permission system when you dig into it happens to be server side managed permissions not server side interpreted permissions.. Remember the item binder than Android added to the kernel. This allowed android to have common shared kernel code for processing permissions.

This is something about Android is the lack of server interpreted permissions. Android is for the ASOP code a purely without server interpreted instead you are looking at server managed where it off loading to the host OS being the Android configured Linux kernel..

Lot of things need to be doing attack surface reduction lot of ways Android was fast off the mark getting rid of server interpreted security..

There is a lot of 2+2=5 from the security point of view. Lot of this 2+2=5 stuff is historic security limitation work arounds copied and copied without even thing should we still be doing this with the current day security technology. This is why with security just because something is old and the common do something does not mean that is the correct way to-do things.

Androids permission system you would have only looked at the surface level stuff mSparks not the deep stuff to see how it in fact implemented to see that its all server managed permissions.

Server managed permissions is the in a lot of ways the foundation bit you need for good security. Think a bit more every server you see with server interpreted permissions has a unique set of code with a unique set of exploited bugs to expand privilege. Server interpreted permissions equals more code to audit because this is reinventing the wheel instead of using the host OS provided wheel.

Olivier
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1790
His boss have not be allowed to merge the above patch. He has not been able to understand why Msparks.

https://gitlab.freedesktop.org/xorg/xserver/-/issues/1665

Alan knows why but want to-do everything to avoid having to write security code that could benefit platforms other than Solaris.

There is no one employed who job is to make sure x.org Xserver or xwayland security implementation is up-to date and no one has been employed to-do this for 20+ years. Android at least there are staff their employed to go over their security implementation and improve it when it possible to so of course Android is quite modern design.

[anda_skoa]

Wayland has no user authentication mechanism

How is that relevant for the matter of confining applications?
And why would it need that given that the system already has that capability and restrictions connections accordingly.

the Wayland display server and the application need to be either the same user, the same user group, or the display server needs to run as root and the socket made world r/w.

Just because the X11 socket is world r/w doesn't necessitate Wayland do do the same.
As oiaohm has explained quite nicely, better options have been available or a couple of decades.

Sand boxed applications don't even need to see the main socket, the sand box will likely have created a new one and shared it with the compositor.
A "run as different user" facility could do the same instead of sharing the main socket protected by system level controls.

X11 the socket accepts/rejects on authenticated users

On the contrary. It accepts all connections and then checks if the connection is permitted or needs to be dropped.

Of course one could use the more advanced system capabilities also with X11 as they work on the socket object, below any of the protocol layers.

[anda_skoa]

Hopefully one day it will not matter if you are using Wayland or X11 what user can access your display server will be enforced by POSIX ACL as in the OS kernel.

That is a good point!

X11 could be upgraded to to use system provided access control.

Something that is currently a different but does not have to remain one.

[anda_skoa]

Well, you wanted more evidence that wayland risks randsomware and malware, that single sentence 100% does the job.

You realize that the sentence refers to how X11 handles it, not Wayland, right?