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

[ssokolow]

Thanks for the info. I guess I will be looking into if and how an app can prevent LD_PRELOAD.

Is there any way to block LD_PRELOAD and LD_LIBRARY_PATH on Linux? - Information Security Stack Exchange

Ah, I see this UI when installers ask for permission. Thanks again, all this seems somewhat complicated.

Basically, Windows Vista normalized self-sudo-ing installers because it still had no package manager.

[Weasel]

No as you describe it that sounds insane. I can't believe this. What does "same" privilege mean? Just the same level, default level?

In short, essential and useful features must be available, no matter if they're a security risk or not. Of course, for security, we must limit them to privileged users or processes or whatever. X11 does not limit them (without security extensions that are broken and result in less functionality), but that's still better than not having them at all. Functionality trumps security. Functionaly with security also trumps the former, though. But security with no functionality is the WORST.

Wayland doesn't give a shit about privilege level or users or whatever. It literally doesn't allow anything to use such functionality. It treats absolutely everything the same but restricts everything and that's the "worst" above. Not like on Windows.

[Weasel]

By contrast, on Linux, you'd need to use either an LD_PRELOAD hack or the ptrace APIs meant for use by debuggers... bearing in mind that, with modern distros, the default sysctl configuration limits ptracing to ancestors of the process being traced and LD_PRELOAD requires being able to set the process's environment variables before launching it.

Linux supports it, though probably not by default in your distro. Wine needs it for some apps that make use of it.

sudo sh -c 'echo 0 > /proc/sys/kernel/yama/ptrace_scope'

Note that still doesn't allow a different user to read/write process memory of another user, which makes it totally safe for me, since I separate privileges with users (including internet access); the most privileged user and the only one which can sudo doesn't even have access to the internet.

[indepe]

In short, essential and useful features must be available, no matter if they're a security risk or not. Of course, for security, we must limit them to privileged users or processes or whatever. X11 does not limit them (without security extensions that are broken and result in less functionality), but that's still better than not having them at all. Functionality trumps security. Functionaly with security also trumps the former, though. But security with no functionality is the WORST.

Wayland doesn't give a shit about privilege level or users or whatever. It literally doesn't allow anything to use such functionality. It treats absolutely everything the same but restricts everything and that's the "worst" above. Not like on Windows.

Not that I would know more about it than anyone here, this is just how I see it:

Microsoft's own network/email were just hacked and MS decided to up the priority of security sooner than planned. There is a general trend.

Wayland see themselves as a standards body and nowadays security by default is considered more and more essential. It's just not going to happen that they will offer anything as a standard that would be a known security hole.

Additionally it looks like Red Hat isn't going to provide Wayland with the mission and/or the resources to define all those things as standards that we would like compositors to have in common.

[ssokolow]

Linux supports it, though probably not by default in your distro. Wine needs it for some apps that make use of it.

sudo sh -c 'echo 0 > /proc/sys/kernel/yama/ptrace_scope'

I hope you weren't intending to disagree with what I said, because you just confirmed it with a demonstration.

[ssokolow]

Wayland doesn't give a shit about privilege level or users or whatever. It literally doesn't allow anything to use such functionality. It treats absolutely everything the same but restricts everything and that's the "worst" above. Not like on Windows.

This is "GNU half-assed their implementation of ELF" all over again. The original design for Wayland calls for a mechanism for sudo/UAC-esque launching of applications with elevated privileges so they can access APIs restricted to higher privilege levels... it's just that, aside from KDE's proprietary extensions that are only accessible to processes launched as "KWin Scripts", nobody has bothered to implement any such APIs or a mechanism to gate access to them and "Well, we won't implement it. We're fine with packing everything we believe users are allowed to want into the compositor process" from GNOME has had a chilling effect on attempts to design any kind of standard solution.

There is hope on the horizon though. Since nVidia started supporting GBM and Red Hat started sunsetting X.org, we've started to see KDE and wlroots wake up and push forward more and more "we don't care if GNOME implements it. We/our users need this" solutions and, combined with KDE 6 working on a release cycle more favourable to being a distro's default desktop, it's possible the more distant future will see GNOME become more marginalized. (Plus, we're starting to see projects like LibrePCB and the Dolphin emulator saying "We're sick of closing bugs with 'WONTFIX: Not our bug'. From now on, our project will only run on Wayland via XWayland. Wayland, wake me up when you've got your sh*t together."

[Weasel]

I hope you weren't intending to disagree with what I said, because you just confirmed it with a demonstration.

No disagreement, I was just giving an example and how it can directly support it.