Service Desk (from firstname.lastname@example.org): New Security Issue
Original reporter: mutter: Insecure handling of /tmp/.X11-unix/
Area: Platform component
While looking at a merge request for KWin, I discovered a flaw in the Xwayland socket creation code it introduced. I was told that at least mutter and wlroots have similar code and are also affected, I'm informing both projects about it.
The /tmp/.X11-unix/ directory contains sockets for each local X display and is thus shared between all users on a system. To allow this, the directory is usually world-writable. To prevent that the sockets created by one user can be messed with (removed, replaced, ...) by other users on the system, it's important that the directory is owned by root:root and has the sticky bit set. (Alternatively, owned by the user on single-user systems).
Xorg servers using Xtrans ensure that the directory has the correct properties and refuse to create the socket if the permissions are not secure: https://gitlab.freedesktop.org/xorg/lib/libxtrans/-/blob/3b5df889f58a99980a35a7b4a18eb4e7d2abeac4/Xtransutil.c#L457
The code for Xwayland socket creation in mutter does not verify the permissions of an existing /tmp/.X11-unix/ directory: https://gitlab.gnome.org/GNOME/mutter/-/blob/91229e824e3503b92f3e887ff1a7ebbe352f5f32/src/wayland/meta-xwayland.c#L630 This means that if another user created /tmp/.X11-unix before, that user has full control over the created sockets, or if that user created it as a symlink, those sockets will be written into an arbitrary location chosen by that user.
On systems with systemd, /usr/lib/tmpfiles.d/x11.conf usually creates the directory with the proper permissions on boot, so those configurations aren't affected unless something deletes the directory beforehand, therefore allowing users to recreate it as their own. The existence of the mkdir call I linked shows that it's seen as a possibility that the directory wasn't created before.
I should note that my finding on the KWin MR is (in hindsight, unfortunately) public already, but I don't think there's a high chance to stumble upon that unintentionally.
Please let me know if you have any questions or would like a review.
BTW: It's not really clear to me whether the "Name" field on the security report form is about the reporter's name or the name of the issue.