KDE On Wayland: "The Biggest Thing Needed Now Is Adoption By 3rd Party Apps"

[oiaohm]

A perfect demonstration of a complete lack of understanding of the POSIX architecture.

That is a linux permissions problem (if it was true, which is highly controversial), not a display server problem. You can't fix POSIX permission problems by changing the display server, any more than you can change the tire on your car by having the local authority resurface the road.

Key thing to remember Posix permissions/security only applies to files.

No you need to learn X11 architecture. There is 4 key time frames.

1) The early UMS drivers. Yes User Mode Setting drivers this are the early X11 graphics drivers. Requirement full access to /dev/mem these are levels of isnane you need root to use them and no security from Posix because basically nothing is a file. When I say insane early X11 servers have user space x86 emulators to run graphical card include firmware/rom to control the graphics card for these early UMS drivers.

2) DRI1 Still UMS still basically nothing is a file so not secure not using posix. Lot of totally insane stuff like platform emulators has been removed..

3) DRI2 Start of KMS so somethings are a file. But your graphics card memory is like GEM where nothing is a file. Wayland developers against gem proved that you could basically guess GEM handles and access other data. This is the level of current day closed source Nvidia graphics drivers.

4) DRI3 that Wayland after 2013 requires and this only comes into existence in 2013. Yes early version of Wayland uses insecure DRI2/GEM. This has DMABUF for userspace to request memory allocations on the GPU and due to DMABUF being a file handle POSIX permissions apply.

Fun point the OS that X11 was first developed for was not a POSIX architecture and it basically taken until 2013/DRI3 to make X11 protocol in fact conform to POSIX architecture. Yes the fact that Nvidia closed source driver userspace X11 driver need deprecated not POSIX compadible interfaces that are DRI2 and earlier to function should have alarm bells running.

When I say Nvidia driver is broken I am not kidding. It broken in so many ways it not funny.

Please note this is not a Linux permission problem this is a problem for every OS using X11 that has not upgraded to DRI3.

By the way the performance issue where you don't want to run a X11 compositor is simple really.

You look at you swapchain counts. X11 bare metal good driver for bare metal swapchain count =2 without compositor. You start compositor its Nvidia bad driver under wayland so this is +4 to your swapchain count when you start a compositor a good driver this will be +2.

Latency 99% of the graphical output system aligns swapchain count.

Now lets do a Wayland compositor.
Bare metal wayland compositor good driver swapchain count 2 bad driver swapchain count 4. Start xwayland swapchain count +0 that right +0 does not increase at all. Start another wayland compositor on top swapchain count +0.

Using buffers in userspace that have posix security the way Wayland does you don't need to increase swapchain count to create secure separation.

The reason why Linux/Freebsd Nvidia closed source drivers is so much trouble with Wayland compositors is that the Nvidia closed source drivers are an insecure mess because they are based on deprecated X11 API/ABI and ideas where making graphics stack incompatible with posix for so called performance was called acceptable.

Please note I said so called performance 2013 different graphics driver developers benchmark all the different claimed reasons for not integrating with the OS posix security and memory sharing items the result was all the other methods resulted in poorer performance as well as being totally insecure.

[mSparks]

Key thing to remember Posix permissions/security only applies to files.

Yet another perfect demonstration of a complete lack of understanding of the POSIX archetecture, this time a real dozy.

in POSIX "everything is a file".

https://en.wikipedia.org/wiki/Everything_is_a_file

So take what you said after that and put it in the recycle bin, it was founded on a fundamental lack of understanding of the OS architecture.

[oiaohm]

Yet another perfect demonstration of a complete lack of understanding of the POSIX archetecture, this time a real dozy.

X11 is not POSIX. Not everything in Linux is posix in fact every OS claiming POSIX compatibility has items that are not POSIX compadible.

https://www.commandlinux.com/man-page/man7/drm-gem.7.html

The kernel will return a 32bit handle that can be used to manage the buffer with the DRM API.

This is from DRI2. That 32bit handle is not a file.

DRI3 is when you find handles like that being files.

mSparks the X11 graphical stack before DRI3 is not Posix compatible. Yes everything X11 before 2013 is not POSIX compatible. For a POSIX OS to run X11 with parts before 2013 results in having to disable/bipass POSIX design of "everything is a file" and do many strange handles.

Also break out your X11 documentation and notice how many handles X11 protocol have that are also not file backed.

This problem does not just stop at Linux. Under Windows everything should use windows designed Handles and Objects you look into Nvidia drivers on Windows and you find o dear Nvidia is making their own stuff up here as well so not correctly integrating with OS security.

The first graphical interface system ever to follow POSIX design rules is 2013 wayland using DRI3 with the implementation being Weston.

[mSparks]

X11 is not POSIX.

"no shit shirlock"
X11 is not a unicorn dressed in pink either.
Linux is POSIX.

https://en.wikipedia.org/wiki/POSIX

X11 is a filetype defination.
xorg-server is an application/process that runs on Linux that can interpret X11 files and has all its permissions managed by the filesystem and SELINUX permission system (which are also files).
Wayland is a filetype defination.
weston/sway and their variants are applications/processes that runs on Linux and has all their permissions managed by the filesystem and SELINUX permission system (which are also files).
xwayland is an application/process recompiled from xorg-sever that runs on Linux that can interpret X11 files and save them as wayland files.

If the permissions managed by the filesystem and SELINUX permission system are broken, switching from xorg-server to sway WILL NOT FIX them, switching from X11 to Wayland doing anything of value to any permission related problem is about as realistic as a promise of a real life pink unicorn for International Tree Day

You are as good as claiming switching from .DOCX to .RTF will improve the spelling in a text document, and declaring .rtf will soon replace all .docx files.

I mean sure, it is hillarious to listen to, but also quite sad.

[oiaohm]

"no shit shirlock"
X11 is not a unicorn dressed in pink either.
Linux is POSIX.

Stop right there. Linux is what is classed as POSIX like/Unix like that means it contains parts that are not POSIX.

xorg-server is an application/process that runs on Linux that can interpret X11 files and has all its permissions managed by the filesystem and SELINUX permission system (which are also files).
Wayland is a filetype defination.
weston/sway and their variants are applications/processes that runs on Linux and has all their permissions managed by the filesystem and SELINUX permission system (which are also files).
xwayland is an application/process that runs on Linux that can interpret X11 files and save them as wayland files.

Nothing you wrote here means anything. Please tell me from selinux how do you identify that gem handle 10 owns to process 10 and that process 11 should not be access it. DRM GEM handle is not file so Selinux has no control over it.

Now 2013 Wayland and new that handle would be DMABUF a DMABUF is a file handle on the OS side so selinux security can be applied. So a DMABUF filehandle that owns to process 10 Selinux can say that process 11 cannot access it.

Bewarned Nvidia close source driver has their own version of GEM handles inside their driver that totally bypass security under Windows and Linux in the same way GEM does in DRI2.

[mSparks]

Stop right there. Linux is what is classed as POSIX like/Unix like that means it contains parts that are not POSIX.

Instead of continuing to spout utter garbage, perhaps try and grasp some of the fundamentals of what you are talking about.
e.g.

https://en.wikipedia.org/wiki/Inspur_K-UX

Please tell me from selinux how do you identify that gem handle 10 owns to process 10 and that process 11 should not be access it.

https://docs.oracle.com/en/learn/ol-selinux/#introduction

[oiaohm]

Instead of continuing to spout utter garbage, perhaps try and grasp some of the fundamentals of what you are talking about.

Certified Unix is kind of a joke. You pay money you pass the operation tests that a Unix requires if you happen to have non unix behaviors you pass. Certified Unix only has to be a Unix like.

mSparks give me the selinux rule to prevent process 11 from access process 10 dri/DRM gem buffers when you have granted both local access to X11 because both are X11 applications. I will tell you now I have done selinux courses. There are particular things that are impossible for selinux to protect against.

Don't tell me to go learn selinux you need to. If I am wrong you need to be able to put up the correct selinux rule.

[mSparks]

Certified Unix is kind of a joke. You pay money you pass the operation tests that a Unix requires if you happen to have non unix behaviors you pass. Certified Unix only has to be a Unix like.

mSparks give me the selinux rule to prevent process 11 from access process 10 dri/DRM gem buffers when you have granted both local access to X11 because both are X11 applications. I will tell you now I have done selinux courses. There are particular things that are impossible for selinux to protect against.

You add SELINUX meta data to the executable of process 10, then do not give process 11 permissions to use it.
worked example in that link.

here's similar for httpd

https://linux.die.net/man/8/httpd_selinux

Don't tell me to go learn selinux you need to. If I am wrong you need to be able to put up the correct selinux rule.

Nothing you should need to learn
It should come set up with your distribution, and bug report to them if it doesnt work right.

[oiaohm]

You add SELINUX meta data to the executable of process 10, then do not give process 11 permissions to use it.
worked example in that link.

That works with DMABUF does not work with DRM GEM handle. When you gave access to X11 as a X11 client application you have just given complete access to the complete area of the GEM buffer that the GEM handle is a pointer inside. GEM buffer does not own to any process not even 0. GEM buffer is not controlled by selinux in anyway.

I said for a DRM GEM handle. This non file items that don't have process information connected.

This is what happens when people don't understand the low level. They setup selinux rules that they think block something that in reality don't block it at all.

This flaw was documented be a Intel developer working on Wayland in 2013 leading to the Wayland protocol moving to DMABUF yes he set up a selinux rule exactly how you described and walked straight past it. Yes that still works today. There is a reason why you should be wanting DRI3 drivers the problem was big enough to issue a new DRI major number.

Lot of security problems on Linux with graphical trace to different items deciding not to be file handles and do their own thing so not integrated with security so selinux and posix permission rules don't work.

Its like the problem with PID numbers and recycling. This is a case where the POSIX standard breaks the rule that everything is a file and now you have a stack of issues.

XACE with X11 never end up working right for the same kind of reasons X11 protocol has stacks of things that are own custom buffer handle solutions that don't integrate with OS security in any simple way.

[mSparks]

GEM buffer does not own to any process not even 0.

Tell me you dont know what a buffer is without telling me you don't know what a buffer is.

I can think of a bigger problem using exactly the same logic., the keyboard buffer does not own any pink unicorns. Wayland is never going to be able to secure the keyboard buffer if it cant cut the hair of pink unicorns to feed the mouse process.