XWayland Adds "-Output" Option For Better Rootful Fullscreen Control

[mSparks]

ERR_ISO27001_PROTOCOL_ERROR

And yet, in contrast to X11 not a single ISO27001 cert to back up any of your assertions. Who do you think you are fooling?

You were the one that made the big thing about ISO27001, does it not matter any more?

[oiaohm]

And yet, in contrast to X11 not a single ISO27001 cert to back up any of your assertions. Who do you think you are fooling?

You were the one that made the big thing about ISO27001, does it not matter any more?

Protocol error mSparks presenting iso27001:2013-2015 and think it means anything.

You have not presented a secure X11 screen lock solution. xsecurelock they document themselves it flawed.

https://github.com/google/xsecurelock?tab=readme-ov-file#known-security-issues

By the way 27001:2013-2015 is a joke.

https://advisera.com/27001academy/explanation-of-11-new-iso-27001-2022-controls/

There a new control mSparks.

A.8.12 Data leakage prevention

That was not in 2013. Yes that applies to screenlockers. So now they in fact need to work all the time not some of the time opps up like X11 screen lockers have been..

https://www.isms.online/iso-27001/annex-a/8-1-user-endpoint-devices-2022/

This one contains something better to quote.

Whereas ISO 27001:2022 Annex A Control 8.1 covers all user endpoint devices such as laptops, tablets and mobile phones, the 2013 Version only addressed mobile devices.

That right under 2013 your a desktop you get to jump over even lower bar in may places though complete ISO27001:2013 because it classed as you can patch non moving machine up with physical security. Major change to 2022 is all machine must be to the same security standard.

mSparks I have not been quoting 27001:2013-2015 because those will not help you get a ISO27001:2022 certificate. ISO27001:2022 does not allow you to use employee training or security guards to attempt to cover up flawed items like X11 screen locker in most cases instead is now use a different solution that does not have the problem or fix the software.

I just need to wait I know the certificate you quoted is not getting updated once that happen you mandating me provide a certificate will backfire badly. I am willing to be here for the next 12 months mSparks..

[mSparks]

By the way 27001:2013-2015 is a joke.

And yet still more than anyone has managed with anything wayland.

Yes that applies to screenlockers.

Does it not apply to compositors to?

https://github.com/schauveau/sway-keylogger

Not to mention the fact that XWayland is just plain X11

now they in fact need to work all the time not some of the time opps up like X11 screen lockers have been..

which is presumably why google have been updating and fixing xsecurelock.

You gonna need more than this fluff if you want to convince anyone Redhat knows more about ISO27001 than google, when Redhat haven't managed a single ISO27001 since RH7, and google has all its sites under a current cert while not using or supporting wayland.

[oiaohm]

https://github.com/schauveau/sway-keylogger.

Can this be prevented yes it can.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/sect-security-enhanced_linux-working_with_selinux-disable_ptrace

Turns out LSM can disable ptrace on a per application base.

It is also possible run wayland compositor as different user just commonly not done. Its like the arguement that you cannot run root applications with wayland when the problem is sudo by default does not preserve XDG_RUNTIME_DIR and WAYLAND_DISPLAY.

Yes this is another case mSparks cannot read.

The purpose of this project is to illustrate how the strace utility can be used to catch all input events (mouse, keyboards, ...) within a Wayland session when the compositor is not protected against PTRACE.

Why is that last bit of sentence if the wayland compositor is not protected against PTRACE. Did not cross you small mind mSparks that there is a configuration you can apply that prevents ptracing Wayland compositors.

X11 server running as your own user without protection against ptrace has exactly the same flaw as what was just demoed there against sway.

Now before you go LD_PRELOAD you block LD_PRELOAD by setting either SUID or SGID on the program also setting file capabilities on application(yes this include drop of capability. Yes you can create a SGID group called compositors that is no body user apply that to Wayland compositors and LD_PRELOAD no longer works. Lets say you drop by file capabilities raw netwokring(as in ping network) something no wayland compositor is going to use again no LD_PRELOAD . Yes running the compositor as a different user is another counter to the LD_PRELOAD and ptrace from user.

which is presumably why google have been updating and fixing xsecurelock.

https://github.com/google/xsecurelock?tab=readme-ov-file#known-security-issues

Most these issues are inherent with X11 and can only really be fixed by migrating to an alternative such as Wayland; some of the issues (in particular the gamepad input issue) will probably persist even with Wayland.

Learn to read mSparks. The major issue with xsecurelock cannot be fixed without either altering X11 protocol or migrating to Wayland. Since google developers are only doing maintenance on xsecurelock and not working on upstream x.org they are not fixing the major flaws in xsecurelock. Yes Google developers plan is to migrate to alternative like it or not.

Google developers with xsecurelock only did 4 commits for all of 2023 and only 7 commits for all of 2022. mSparks the work on xsecurelock has been trending down for a while and you have not noticed that. They are not working on fixing the flaws in xsecurelock.


mSparks really present evidence that google has been working on xsecurelook. Yes the 4 commits last year.
1) version bump Not feature work.
2) Fix issue with autoconf this build error not a security fix.
3) XSECURELOCK_SAVER_STOP_ON_DPMS to XSECURELOCK_SAVER_STOP_ON_BLANK again not a security fix as such. In fact this change for people who did not notice who were using the old value caused security problem.
4)Support /usr/lib/xscreensaver for xscreensaver savers too. Again not a security fix support a different location for xscreensaver.

This is maintenance work. Not repair work.

Last security work on xsecurelock at all is sep 2022 yes 27001:2022 is released October 2022. Yes scare point you have missed mSparks as soon as ISO27001:2022 released xsecurelock development has basically been put into maintenance mode with the developer who use to work on xsecurelock now working on KDE and Gnome screensavers/screenlock. The close up by SSSD on smartcard support that end up part funded by Google and worked on by Google developers in 2022.

ISO27001:2022 changed developer allocations inside google and we can see this from where developers are now submitting code.

[mSparks]

Most these issues are inherent with X11 and can only really be fixed by migrating to an alternative such as Wayland; some of the issues (in particular the gamepad input issue) will probably persist even with Wayland.

Learn to read mSparks.

ME learn to read...
LOL you quoted the important bit yourself.

Now before you go LD_PRELOAD

That keylogger doesn't use LD_PRELOAD, it uses the ptrace functionality in the wayland screenlockers and password wallets.

There is no permissions difference between xorg-server and Wayland compositors, they both use exactly the same system libraries and have exactly the same system permissions.

The only thing wayland does is break everything while offering nothing.

The reason you cant find any iso27001 certs for wayland is no one is going to go through the time and expense to certify wayland based stuff until it is at least at feature parity with X11, which is at least a decade away - likely never (cos, you know, X11 was designed by MIT grad students, and wayland was designed by people who couldnt even get a job working for google).

[oiaohm]

ME learn to read...
LOL you quoted the important bit yourself.

Maybe I have been ingoring that bit because you are incompetent.

https://access.redhat.com/articles/3230621
You link usbguard up to your screen lockder with correct usbguard policies that is simple to do under KDE and that gamepad input device problem goes away.

It shows different flaw in xsecurelook is that it not coded to integrate with usbguard.

Think about it you are running a secure system you are going to want a USB device firewall.

You must never of setup a properly secured Linux Desktop. Anyone who has knows the Google developer of xsecurelock with the gamepad issue is talking about failure to setup a USB firewall and connect to the screenlocking.

I do wish the USBguard firewall stuff was connected up by all screen lockers on Linux by default and a better way of changing profiles in usbguard was setup for it.

That keylogger doesn't use LD_PRELOAD, it uses the ptrace functionality in the wayland screenlockers and password wallets.

Same kind of ptrace attack works against xscreensaver that is core to xsecurelock.

https://media.defense.gov/2019/Jul/16/2002158062/-1/-1/0/CSI-LIMITING-PTRACE-ON-PRODUCTION-LINUX-SYSTEMS.PDF

Secure production systems you are meant to have disabled generic ptrace.

There is no permissions difference between xorg-server and Wayland compositors, they both use exactly the same system libraries and have exactly the same system permissions.

There is permission difference. I pointed it out to you before when you copy pasted under Wayland you use a file handle with that file handle LSM permissions travel protected by kernel space with it because of the OS kernel. When you copy paste under X11 you use a memory buffer so X11 server has to attempt secure LSM information in userspace. X11 selinux security stuff that you pointed to as a X11 trump card is in fact open to being attacked by ptrace and ld_preload so allowing false credictal information to allow X11 operations that X11 server should have blocked that would be blocked under Wayland compositors..

The ptrace/LD_PRELOAD containment is kind of critical. Yes X11 server and Wayland compositor both have to be protected from ptrace/LD_PRELOAD but you can in fact do less trouble against wayland compositor than X11 server. You don't get to bipass selinux rules under Wayland just by ptracing or LD_PRELOAD the wayland compositor like you do under X11 when you ptrace/LD_PRELOAD the X11 server.

Yes lot of people who are clueless like you think hey we found a Wayland compositor ptrace/ld_prelaod keylogger we win the argument. The reality here if you apply the same attack against the X11 server and remember you have rootless X11 server you and someone has not configured to block ptrace/ld_preload you get to fake selinux identity under X11 server so allowing operations that by the selinux rules that are right should have been forbid.

Level of disaster using ptrace/LD_preload is in fact worse against X11 server than against Wayland compositor.

mSparks there is permission processing differences you have ignored. Wayland protocol choice to use file handles to keep permission processing protected by the Kernel not the userspace. Having permission handled by user-space when you don't have to in a lot of ways is asking to be hacked..

The reason you cant find any iso27001 certs for wayland is no one is going to go through the time and expense to certify wayland based stuff until it is at least at feature parity with X11, which is at least a decade away.

No I can find them. Problem is iso27001:2022 certificates don't have to be published publicly in most places. The items that have iso27001:2022 certificates on Wayland parts is embedded systems at this stage. But that proves they can pass.

Your no one is way to broad. Embedded users/developers of wayland is all ready feature parity with X11 for what they use and they need ISO27001:2022 for new solutions.

Also you seem to have missed my point.

X11 server if people wish to keep on using on bare metal they need to get ass and work on the upstream and update the X11 protocol. Redhat is not going to do the work for you. ISO27000 series and other certifications that government mandate are stopping messing around.and final removing the loops holes.

Yes it been insane that desktop OS with broken design screen locker has been able to pass ISO27001 just because its a laptop/desktop computer yet if it was a mobile phone OS it would fail instantly.

Yes it one of those stupid things take a pinephone install your companies X11 desktop Linux that has a ISO27001:2013-2015 certificate on it and you have broken ISO27001:2013-2015 welcome to double standards for you because mobile and desktop are difference in ISO27001:2013-2015 and before.

Yes a mobile phone approved for all version of the ISO27001:2013 had to have a functionally correct screen locker or it did not pass to be used but the laptop the user is traveling with it could have a non functional screen locker. ISO27001:2022 says mobile and laptops and desktops have to be treated the same this is why the boot finally drops.

[mSparks]

under Wayland you use a file handle with that file handle

Everything under *nix is a file handle, you don't understand *nix

Same kind of ptrace attack works against xscreensaver that is core to xsecurelock.

And all the wayland screenlockers, you don't understand *nix

When you copy paste under X11

Everything under *nix is a file handle, you don't understand *nix

Yes lot of people who are clueless

You are the one saying "everyone on linux" is going to abandon 40 years of software development by the best minds on the planet that has consistently shown it offers the highest levels of security, to adopt a random collection of badly written system calls by a bunch of software pirates that breaks everything and offers nothing, "because iso27001".

Despite you not being able to offer a shred of evidence of an iso27001 cert being issued to wayland in the decade and a half since it was released.
It seems you are the clueless one here.

No one is going to adopt wayland, and no amount of hyperbole is going to change that, least of all your iso27001 fantasy, on a thread about trying (and obviously failing) to make wayland useful by getting it to support X11.

[oiaohm]

Everything under *nix is a file handle, you don't understand *nix.

This is nothing more than myth. Plan 9 developers make this really clear. Its you who don't understand Unix and it issue of not obeying it own rule.

mSparks PID is not a file handle and many more parts of POSIX standard are not file handles. Everything is a file handle until its not. Plan 9 everything is truly a file.

https://matt-rickard.com/plan9-everything-is-a-file

Reality check here everything under unix is not file handle. With security you not using file handles with Unix equals you most likely have a security exploit.

Unix/Posix has lots of choice you can do that avoid file handles.

Core bit of X11 avoid using file handles. X11 does not follow core Unix design.

https://en.wikipedia.org/wiki/MIT-SHM

In the 1.15 release of the X.org server^[2] the MIT-SHM extension gains two additional requests: 'X_ShmAttachFd' and 'X_ShmCreateSegment', to be able to pass shared memory through file descriptors from client to server and from server to client, reducing the number of copy operations further.

Yes this is 2013 when this was added. Issue here is before 2013 X11 is not using file handles for memory operations and X11 optional to use filehandles in these places since 2013 not mandatory..

mSparks here a shock horror the OS that "Project Athena" the base of what comes X11 was not developed for Unix at first but instead IBM MVS and Dec VAX that we know today is OpenVMS. Yes OpenVMS and MVS don't have the design goal of everything be a file.

X11 like it or not was not designed for Unix instead it was shoe horned on top of Unix and it shows for all the places file handles should have been used in the protocol and X11 does not use file handles.. X11 on Unix is really a round peg in a square hole that allowing issues that should not happen.

And all the wayland screenlockers,

mSparks the reality is not difference be it xscreensaver or a Wayland screenlocker you have to apply counter ptrace/LD_PRELOAD security otherwise you security is wrong. So exploit using ptrace or LD_PRELOAD works this is nothing more than a system configuration error.

The issue I raised with xscreensaver/xsecurelock has nothing todo with ptrace/LD_PRELOAD. The failure if applications don't cooperate to lock the screen at all this is a documented xscreensaver problem and it documented on the xsecurelock page I have pointed you to many times. This does not depend on something you mitigate by altering security setting. . Also the case that the screen locker under X11 fails and the output unlocks again not something that has anything todo with ptrace/LD_PRELOAD.

Why bother with giving you the ISO certificates when you get what Unix is wrong mSparks.

Even worse X11 was never designed for Unix instead was design to be a common GUI between VMS and MVS resulting in a huge stack of security flaws in the design. Issues with X11 are right at the core. The way X11 screen locking and memory operations working without being correct is core X11 protocol issue.

Also note mspark first version of the Wayland protocol like X11 protocol was not everything is a file protocol. Wayland with DRI3/DMABUF instead of GEM handles changed to everything is a file model.

selinux intergation with X11 would have been way less complex if it followed everything is a file model.

abandon 40 years of software development

Horrible yes it been 40 years of hacking something without dealing with the core problems. Best Minds cannot magically turn a pigs ear into a silk purse.

Most people miss that X11 protocol was not design with the Unix mantra of everything is a file"

Please note mSparks it gets worse there is no written evidence that the Unix before X11 exists(June 1984) that the Unix mantra of "everything is a file" exists the first appearance on the record of everything is a file.

https://unix.stackexchange.com/questions/470828/history-of-the-saying-everything-is-a-file

When you trace the saying.

UNIX philosophy that “all files are simply a stream of bytes" this is pre 1990. Yes "Unix everything is a file" is post 1990. In sanely new saying and was not a Unix philosophy before 1990.

Everything under *nix is a file handle, you don't understand *nix.

Sorry its not me who does not understand Unix but you. Plan 9 of 1992 is the only OS where everything is a file. No Unix has ever been everything is a file handle. *nix can cover plan 9. But Linux is not plan 9 your normal Unix likes in the class of Linux and BSD are also not everything is a file handle.

Its a surprise to most people how new that everything is a file idea really is. X11 core protocol is too old to be designed with everything is a file idea because that idea did not exist in Unix, VMS or MVS of the time of X11 core development..

"Everything under *nix is a file handle" is only something idiots say who have never read the posix standard or know the issue of everything is file and that it a shock young term that cannot be applied to most *nix because their core designs are too old and pre date that design concept...

[oiaohm]

Most people miss that X11 protocol was not design with the Unix mantra of everything is a file"

Please note mSparks it gets worse there is no written evidence that the Unix before X11 exists(June 1984) that the Unix mantra of "everything is a file" exists the first appearance on the record of everything is a file.

https://unix.stackexchange.com/questions/470828/history-of-the-saying-everything-is-a-file

When you trace the saying.

UNIX philosophy that “all files are simply a stream of bytes" this is pre 1990. Yes "Unix everything is a file" is post 1990. In sanely new saying and was not a Unix philosophy before 1990.

Everything under *nix is a file handle, you don't understand *nix.

Sorry its not me who does not understand Unix but you. Plan 9 of 1992 is the only OS where everything is a file. No Unix has ever been everything is a file handle. *nix can cover plan 9. But Linux is not plan 9 your normal Unix likes in the class of Linux and BSD are also not everything is a file handle.

Its a surprise to most people how new that everything is a file idea really is. X11 core protocol is too old to be designed with everything is a file idea because that idea did not exist in Unix, VMS or MVS of the time of X11 core development..

"Everything under *nix is a file handle" is only something idiots say who have never read the posix standard or know the issue of everything is file and that it a shock young term that cannot be applied to most *nix because their core designs are too old and pre date that Unix design concept..

Please note Unix Design Concepts are suggestions not mandates. If you collect them you find over the history of Unix there are Unix design concepts that disagree with other.

[mSparks]

Most people miss that X11 protocol was not design with the Unix mantra of everything is a file"

X11 is a file format.

xorg-server is a file server, for X11 files.

Plus, "everything is a file" isn't a mantra, its an observation - everything is a file, whether you like it or not. The "design mantra" is simply accepting that and making the most of it.

Even wayland system calls end up as a file, just with no meaningful structure behind it and impossible to properly validate.

TLDR: Wayland is utter garbage and everything you believe about it is hyperbolic bullshit.