Originally posted by Weasel
View Post
Announcement
Collapse
No announcement yet.
X.Org Server & XWayland Updated Due To Another Six Security Vulnerabilities
Collapse
X
-
Originally posted by Weasel View PostWhat 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.
Originally posted by Weasel View PostAnd 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.
Comment
-
Originally posted by ssokolow View PostI'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.
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.
Originally posted by ssokolow View PostI'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.
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…
Comment
-
Originally posted by Weasel View PostNice 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…
Comment
-
Originally posted by ssokolow View PostOK, 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.
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).
Comment
-
Originally posted by Weasel View PostThat 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).
Comment
-
Originally posted by indepe View Post
No as you describe it that sounds insane. I can't believe this. What does "same" privilege mean? Just the same level, default level?
...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.Last edited by ssokolow; 20 January 2024, 09:08 PM.
- Likes 2
Comment
-
Originally posted by ssokolow View Post
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.
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.)
Comment
-
Originally posted by indepe View Post
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?
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.)
Originally posted by indepe View Post(I don't think I have noticed any "multi-colored shield buttons" in Windows so far.)Last edited by ssokolow; 21 January 2024, 12:44 AM.
- Likes 2
Comment
-
Originally posted by ssokolow View Post
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.)
Originally posted by ssokolow View PostThe 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.
Comment
Comment