Title, I’m interested to know how Wayland contributes to better security inside the OS - does it have less attack surface than X?
There are a couple of main things that make Wayland useful:
- The IPC sockets are stored in
/run/user/UID, which has file permissions that prevent any users from accessing it except for the user that is supposed to access it. With X11, the IPC sockets are world-writable and saved under /tmp, meaning it is the responsibility of X11 to prevent software running under a completely unprivileged user account (such asnobody) from sniffing all keystrokes, recording the screen, etc. With Wayland, the kernel is able to prevent this kind of attack, no matter how the compositor itself is written. - X11 as a software ecosystem is dying. GUI software libraries (like the upcoming GTK5) plan to drop support for it, drivers are showing signs of bitrot with it, the upstream project is no longer actively developed beyond removing broken bits and fixing the occasional security bug, applications exist that explicitly can’t run on X11 and require Wayland, and many other distros are moving to it. Maintaining support for X11 is, in the long run, not feasible with our current manpower. Moving to something well-maintained is better for security in general.
The usual security benefits people reference with Wayland (like keystroke sniffing prevention) are actually not as useful to us, since there are Wayland protocols in labwc that can be abused to work around some of these limitations.
Okay, that actually makes a lot of sense, I’m just quite distraught at the moment why such a jump would be made without warning since it broke a critical feature for me at a very bad timing.
You seem to be very knowledgeable about the state and developments of diverse OS projects, any tips or resources to learn more about that? just reading docs or whatever never gives such insight into the “meta” of the GNU/Linux ecosystem.
It is very unfortunate, and we put quite a bit of work into seeing if we could get a workaround working before we gave up and accepted that the feature would be broken. For KVM, we actually found a partial workaround (I think you probably saw the thread where I linked to it), but for VirtualBox, it’s just totally broken thanks to Oracle’s code not doing what it’s supposed to.
As a workaround, you could possibly use scripts that will dump the Wayland clipboard contents to a file in the shared folder, then use a script on the host that will copy that to the host’s clipboard? Those could then be bound to keyboard shortcuts that will allow you to do something like “Ctrl+C to copy in guest, Ctrl+Shift+C to dump to shared file, Ctrl+Shift+V in host to load shared file into clipboard, Ctrl+V to paste in host”. How exactly this works will depend on your host OS and display server, but wl-copy and wl-paste will probably be useful on the guest side, and if your host is on X11, xclip will probably let you do the host side of things.
Most of the info I have is from being in the open-source community a lot. A lot of info gets passed around as software develops, and I end up hearing a lot of it since I work with a lot of different developers. (The driver bitrot issue with X11 I’ve experienced first-hand though, as has my workplace.)
Thare are good Linux news sites for hearing about what projects are doing, LWN is one of the better ones. (I don’t have any connection to them, and don’t have an LWN subscription, but I oftentimes read their articles that are old enough to be free.)
That seems like a very good workaround, I feel dumb for not thinking of that. I will try to make that work asap with some bash scripting. If I make it work, is it allowed on the forum to share those scripts then so other users can use them too? If so, where? (will try to make versions for both an x11 and wayland host)
Makes sense, thanks for that info. Don’t really understand what you mean with the x11 driver bitrot issue, never heard of that term being used outside of hardware storage
related:
X Windows System
For reference:
Wayland application isolation
We’ll review that topic of which Wayland compositor again once we port to Debian forky.
Sharing fixes and workarounds for specific issues is allowed and encouraged. If the solutions are of sufficiently high quality, and we have bandwidth available to review these, they may be added to the wiki so all users can find them easily.
How are you getting bitrot with X11? How does that happen?
By “bitrot”, I mean software rot, “the degradation of a software (application) over time even if ‘nothing has changed’”.
As for what exactly I saw that I consider to be “software rot”, the primary example I can think of is the behavior of modern NVIDIA drivers with X11. On at least some systems, the display will “flicker” quite badly (momentary but frequent display corruption) when using X11, but will look perfectly fine under Wayland. Fixing that flicker requires placing the driver in a higher-performance mode which results in increased power draw at idle, meaning one either lives with persistent and very annoying flickering, or short battery life, one of the two.