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

[indepe]

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

Oh, I thought flippping such switches would be the first thing you do voluntarily.

[ssokolow]

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.

I'm talking about the developers of compositors like KWin, Mutter, etc. whose inability to agree on standard APIs forces us to do an end run around their beautiful vision of a security model by not giving us the APIs we need to get sh*t done in a form that works within the security model.

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.

I'll take the JavaScript/WebAssembly approach to security over the Java SecurityManager one, thanks. They may be botching building it out, but the JS/WASM/Wayland approach of "define a language that lacks verbs to talk about dissent" is a form of capability-based security, which is agreed by security experts to be the better approach.

[Weasel]

I'm talking about the developers of compositors like KWin, Mutter, etc. whose inability to agree on standard APIs forces us to do an end run around their beautiful vision of a security model by not giving us the APIs we need to get sh*t done in a form that works within the security model.

How is that their issue? That is literally Wayland's issue.

The whole point of a well-designed protocol or interface is to be something that everyone implements and be good enough for all cases so that you don't have to implement any "private APIs". It's not the job of any specific compositor to extend this. If it has to extend it, then Wayland failed.

I'll take the JavaScript/WebAssembly approach to security over the Java SecurityManager one, thanks. They may be botching building it out, but the JS/WASM/Wayland approach of "define a language that lacks verbs to talk about dissent" is a form of capability-based security, which is agreed by security experts to be the better approach.

Nice appeal to (fake) authority. Nobody cares what those supposed experts say, you know why?

Because it's unusable in context without sandboxing. Maybe it's not a big deal for WASM/JS simply because it's not used outside of the web, but that's probably one of the reasons why to begin with.

Sadly you see, Wayland is not just limited to the web…

[ssokolow]

Nice appeal to (fake) authority. Nobody cares what those supposed experts say, you know why?

Because it's unusable in context without sandboxing. Maybe it's not a big deal for WASM/JS simply because it's not used outside of the web, but that's probably one of the reasons why to begin with.

Sadly you see, Wayland is not just limited to the web…

OK, how about this: It's the graphics API version of not mapping virtual memory addresses for RAM that the program isn't supposed to be able to access.

[Weasel]

OK, how about this: It's the graphics API version of not mapping virtual memory addresses for RAM that the program isn't supposed to be able to access.

That would be a fair point if shared memory didn't exist. But it exists for a reason. A typical system would be completely unusable without it or severely crippled in performance.

For instance, Windows has virtual memory protections, but In Windows you can read another process' memory (and many apps depend on this) if it's same user and same privilege, which is sane. Of course in X11 you can read everything, and that's not sane, but like I said it's better to have functionality than lack of it. "Functionality" here means Windows' sane behavior (i.e. still restricted but not COMPLETELY restricted like Wayland).

[indepe]

That would be a fair point if shared memory didn't exist. But it exists for a reason. A typical system would be completely unusable without it or severely crippled in performance.

For instance, Windows has virtual memory protections, but In Windows you can read another process' memory (and many apps depend on this) if it's same user and same privilege, which is sane. Of course in X11 you can read everything, and that's not sane, but like I said it's better to have functionality than lack of it. "Functionality" here means Windows' sane behavior (i.e. still restricted but not COMPLETELY restricted like Wayland).

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

[ssokolow]

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

I'm no expert but, as I understand it, it's how Windows talks about its equivalent to POSIX concepts like "Effective UID vs. Real UID". If you use UAC to "sudo" on Windows, your User ID doesn't change, but the process's credentials in the NT kernel are updated with elevated privileges. (i.e. a sudo that doesn't require a subprocess or re-exec-ing self in order to elevate the privileges. Thus, the prevalence of those multi-colored shield buttons for elevating privileges in Windows apps, since they don't require a two-process architecture to avoid restarting the program.)

...so, in practical terms, it's basically saying that memory can't be shared between a process running under the indepe user without UAC elevation and a process running under the indepe user with UAC elevation.

I think Microsoft also layered on a lower privilege level that later versions of Internet Explorer or Edge started running their content processes in.

[indepe]

I'm no expert but, as I understand it, it's how Windows talks about its equivalent to POSIX concepts like "Effective UID vs. Real UID". If you use UAC to "sudo" on Windows, your User ID doesn't change, but the process's credentials in the NT kernel are updated with elevated privileges. (i.e. a sudo that doesn't require a subprocess or re-exec-ing self in order to elevate the privileges. Thus, the prevalence of those multi-colored shield buttons for elevating privileges in Windows apps, since they don't require a two-process architecture to avoid restarting the program.)

...so, in practical terms, it's basically saying that memory can't be shared between a process running under the indepe user without UAC elevation and a process running under the indepe user with UAC elevation.

I think Microsoft also layered on a lower privilege level that later versions of Internet Explorer or Edge started running their content processes in.

Not sure I follow. So far I thought, perhaps too quickly, that for any two Linux processes (except the kernel) to access the same memory, it has to be designated by both as "shared memory".

Is it for one Windows process possible to access another process's memory even if that process thinks that it is its "own" memory? Perhaps if both have elevated privileges?
(I don't think I have noticed any "multi-colored shield buttons" in Windows so far.)

[ssokolow]

Not sure I follow. So far I thought, perhaps too quickly, that for any two Linux processes (except the kernel) to access the same memory, it has to be designated by both as "shared memory".

Is it for one Windows process possible to access another process's memory even if that process thinks that it is its "own" memory? Perhaps if both have elevated privileges?

I'm not a Windows programmer, so I'll point you at this StackOverflow answer for an explanation.

To me, it looks like, possibly as a holdover of the ramp of compatibility from Win16 to Windows 9x and onward, the Windows API is more lenient with allowing one process to access the memory of other processes with the same user+priv_level combination if you use the right API calls to indicate it's not just random flailing from memory corruption. (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.)

(Speaking of which, LD_PRELOAD hackery is also how the "Look, I can keylog on Wayland!" demo works and it's not something Wayland is designed to prevent, because Wayland's goal is to prevent X11 from being a hole in the security of things like Flatpak. It leaves preventing LD_PRELOAD hackery to them.)

(I don't think I have noticed any "multi-colored shield buttons" in Windows so far.)

The button in the screenshot here... though I wish I could find a screenshot of various apps I've seen over the years where they just work it into an otherwise ordinary UI (usually in the bottom-left corner of the window) and the result is to enable UI elements that were previously greyed out.

[indepe]

I'm not a Windows programmer, so I'll point you at this StackOverflow answer for an explanation.

To me, it looks like, possibly as a holdover of the ramp of compatibility from Win16 to Windows 9x and onward, the Windows API is more lenient with allowing one process to access the memory of other processes with the same user+priv_level combination if you use the right API calls to indicate it's not just random flailing from memory corruption. (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.)

(Speaking of which, LD_PRELOAD hackery is also how the "Look, I can keylog on Wayland!" demo works and it's not something Wayland is designed to prevent, because Wayland's goal is to prevent X11 from being a hole in the security of things like Flatpak. It leaves preventing LD_PRELOAD hackery to them.)

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

The button in the screenshot here... though I wish I could find a screenshot of various apps I've seen over the years where they just work it into an otherwise ordinary UI (usually in the bottom-left corner of the window) and the result is to enable UI elements that were previously greyed out.

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