5 ms·
> Last week I asked the author of this article to issue a full retraction, because every point is a blatant falsehood. That doesn't sound reasonable. > LD_PRE
by CyberShadow 8y ago
> Last week I asked the author of this article to issue a full retraction, because every point is a blatant falsehood.
That doesn't sound reasonable.
> LD_PRELOLAD hacks don't work if the compositor launches the programs - some simple .bashrc trick won't work, and getting the LD_PRELOAD into .bashrc requires being unsandboxed, which itself opens up a wealth of side channel attacks.
This lists quite a few assumptions. Are there many distributions that provide these assumptions out of the box (specifically, the compositor running all applications, and all applications being sandboxed)?
> >4 - A bug in xorg-server will similarly bring down your X session.
A Xorg server needs to implement:
- the display server
A Wayland compositor needs to implement:
- the display server
- the window manager
- the compositor
- the hotkey daemon
- the screenshotting tool
- everything else that is now unimplementable in Wayland, but needs to be in the Wayland compositor because users need them and Wayland compositor implementers have no choice but to provide the features as API extensions.
I'm not really sure what's XWayland's story security-wise, but from my limited understanding, it is a component that is not going away soon, and allows bypassing some limitations of Wayland's API in order to accommodate X11 clients.
- ddevault 8y ago>This lists quite a few assumptions. Are there many distributions that provide these assumptions out of the box (specifically, the compositor running all applications, and all applications being sandboxed)? It's not the Wayland compositor's responsibility to provide an entire security solution, just like it's not the deadbolt manufacturer's responsibility to install an alarm system and security cameras. This isn't a criticism of Wayland, at best it's a criticism of your Linux distro. Flatpak does answer this question, but fwiw in the Sway camp we're still looking into lighter-weight solutions. >A Wayland compositor needs to implement: - the display server - the window manager - the compositor - the hotkey daemon - the screenshotting tool - everything else that is now unimplementable in Wayland, but needs to be in the Wayland compositor because users need them and Wayland compositor implementers have no choice but to provide the features as API extensions. This is only partially true. wlroots implements screenshots the same way that xorg-server does: by providing an API for exporting pixels to clients. The actual screenshot tool is a standalone program which can crash without affecting the compositor. This design is virtually identical to X, except easier to secure. The same can be said of many of your other points.
- deleted 8y ago[deleted]
- nurettin 8y agoLet's say every attack vector exposed by wayland involves user being root or somehow having sudo access or somehow being exempt in pam or somehow having special access to input devices or being promoted through an ssh config or being promoted through a vpn config. That is still a huge attack vector considering that the userbase is desktop users and not companies with security teams.
- ddevault 8y agoIf you expect Wayland to protect users who give arbitrary programs root access, I have nothing more to say to you.
- nurettin 8y agoI expect attack vectors to be equal or less than X. Also consider what I wrote instead of repeating the same mantra of full root access.
- mort96 8y agoI don't quite understand. A rouge root user in X can just replace the /usr/bin/X binary with their own version which records the screen and logs user input or does whatever they want the next time the user restarts X, or better yet, install a kernel module of their own and have arbitrary code running in ring 0. What exact attack vectors do you see in X which you don't see in Wayland, which actually makes a difference and isn't completely overshadowed by all the other things a root user can do?
- nurettin 8y agoCan you change /usr/bin/X if you are only given access to /dev ?
- coldtea 8y ago>This lists quite a few assumptions. Are there many distributions that provide these assumptions out of the box (specifically, the compositor running all applications, and all applications being sandboxed)? That's irrelevant. If they don't, they should, and it's not Wayland's problem.