X11/Xorg is in a precarious place with Wayland waiting in the wings.
Sadly Wayland "breaks everything" and isn't yet a serious prospect for
anything but a new-broom distro. My personal experiences with Wayland
confirm this - most stuff just fails in weird ways right now. So
there's a window of insecurity or non-functionality between one world
that is dying and one that has yet to be born.
Ditto, Wayland user for... at least four years now; on Sway, even. Happy to help where I can - I'm very comfortably settled into this new world.
There's a lot of assumption around Wayland handling based on the value of "$DESKTOP_SESSION". This is relevant for xdg portals that make screensharing and the like possible.
In the end it's mainly Electron/Chromium things that may need some launch arguments to truly do Wayland. Anything GTK/Qt has been inherent.
I'm using sway (wlroots + xdg-desktop-portal-wlr). Sharing the whole screen works.
I have tried using chrome (stable and unstable) and OBS. OBS uses pipewire to capture (which I believe in turn talks wayland xdg-desktop-portal). I think chromium works the same way (I have the chrome flag "enable-webrtc-pipewire-capturer" turned on). There doesn't seem to be a way to share a single specific window.
There is so much half-cocked or old information out there it is hard to find the right place to look. At the end of the day I'm not sure if xdg-desktop-portal, wlroots, or pipewire need to be improved.
Does that use gnome for the wayland compositor? Not sure what you mean by compiz in this context -- I thought that was an X11 window manager. I see wayfire is a "spiritual successor" of compiz based on wlroots.
I am using sway + wlroots + xdg-desktop-portal-wlr on my system.
Not OP, but right now my biggest unfulfilled use cases are:
- global keybindings (e.g. I would like variations on super+space with extra modifiers to trigger different behaviours in an application launcher, Kupfer)
- remote control (x2x) --- I use this for essentially seamless kvm between different machines driving adjacent monitors
- I have no choice but to use Zoom screen sharing for work
1. How did you do that with X11? I can't quite remember but I think the solution is wayland-compistor specific...
2. Check out Waypipe, it works really well and supports all application types unlike X11 forwarding. It's more like VNC but easy.
3. Last I checked Zoom screen sharing does work via the browser. The only feature I remember missing was screen control. Same experience with MS Teams too.
Yeah, in X anyone can write a keylogger. Or do something really useful with it :-)
(Personally I don't think this is a problem: if the attacker can run programs it's game-over already; just replace "su", "sudo", "firefox", or whatnot with your wrapper script which logs stuff, add ~/.local/bin to PATH by frobbing with shell rc, and presto)
On reflection, almost all of my problems are to do with audio;
pipewire, and it's interaction with pulse, alsa, jack and so on -
being a 0.1% "pro-audio" user I probably have needs that the average
Wayland user doesn't see.
You can run a wayland session without the pipewire audio stack (pipewire will still be installed, but for the video media sessions).
The pipewire audio stack replaces pulse and jack, it doesn't play well with Jack and Pulse running on the side.
It does work well for me (including doing a bit of recording and mixing with Ardour) but, from what I understand, the pro audio use cases, mainly low latency, will be a focus for the version 1.0: https://www.phoronix.com/news/PipeWire-1.0-Release-Plan
Screen sharing needs pipewire. My personal experience with pipewire is fine through, just lack good documents, and finding required softwares for screen sharing itself can puzzle quite some people, so far from easy-to-use.
I want to login to my computer over some remote protocol (i.e vnc, rdp), execute "sudo systemctl reboot", wait a little, and log in again.
For this I think I need remote access to a logged out session, which as of my last check is impossible. (It's also poorly supported by gnome on x though)
The use case here is that I'm in a different physical location to the computer and want to remotely connect and run everything I'm working on on the remote computer in my remote window manager, including a browser and ide and terminal and so on.
Maybe I was too literal. The problem isn't executing the reboot command. The problem is logging in remotely to a computer that hasn't been logged into locally since it booted.
In particular the problem is that if I'm going to be remote for an extended period of time I have to ensure that nothing could interrupt the local session, and there's no fix if it does.
:) Maybe we need more of this kind of attitude, I don't know. But I'm
an old guy. Leave me in peace on my porch with my rocking chair and
whiskey bottle.
I just installed KDE Plasma+Wayland today on mint Linux. Working great so far, although I’m not noticing a large difference in performance, maybe my specs are good and load is light.
Wayland works fine in modern machines. On X.org security, if you plan to something sensible in the CLI, just switch into an VT with Termux/Screen,
do your work here and then restore your session under X.
Or use UXTerm with the keyboard lock option from the menus, where your input
it's bound to the XTerm window and nothing else can read or snoop it. In theory,
but I didn't spawn 'xev' to test it.
Thus, head to an VT, there are good Unicode fonts (Unifont for instance) for basic needs. And with fbpdf2, fbi and mpv (among SDL_VIDEODRIVER set to fbcon/drm) you can spawn framebuffer/DRM based image/video and PDF viewers in a hurry.
To be fair, these are invalid attack vectors in the first place. Attackers automatically gain the full access to desktop sessions as soon as a connection is made to the X server. It's already vulnerable by design, so there's almost no need to look for exploits.
p.s: So, all in all, this doesn't exactly make Xorg more dangerous than before, especially w/ rootless X being widely used.
Yeah, rootless is key here. This allows RCE, but that is usually not valuable because the X server is running with the same permissions as the application.
However these vulnerabilities are old enough that they would have been useful when X always ran as root.
Mh. Though at that point you might be looking at desktop computers, and access to the current users file might be good enough. Sure, you can't install printer drivers via non-root X servers, but you can probably exfiltrate their local browser data (credit to XKCD[1]).
It's another hole where vulnerability assessment is kinda... wonky.
38 comments
[ 4.5 ms ] story [ 155 ms ] threadX11/Xorg is in a precarious place with Wayland waiting in the wings. Sadly Wayland "breaks everything" and isn't yet a serious prospect for anything but a new-broom distro. My personal experiences with Wayland confirm this - most stuff just fails in weird ways right now. So there's a window of insecurity or non-functionality between one world that is dying and one that has yet to be born.
There's a lot of assumption around Wayland handling based on the value of "$DESKTOP_SESSION". This is relevant for xdg portals that make screensharing and the like possible.
In the end it's mainly Electron/Chromium things that may need some launch arguments to truly do Wayland. Anything GTK/Qt has been inherent.
This is with WebEx which I think uses WebRTC; it got funny when I disabled too much fingerprinting [in my browser].
I've managed without specific-app-sharing by using workspaces
OBS worked okay the last I toyed with it, IIRC using Pipewire for the capturing.
OBS works fine from what I've heard but must admit I don't use it myself.
I have tried using chrome (stable and unstable) and OBS. OBS uses pipewire to capture (which I believe in turn talks wayland xdg-desktop-portal). I think chromium works the same way (I have the chrome flag "enable-webrtc-pipewire-capturer" turned on). There doesn't seem to be a way to share a single specific window.
There is so much half-cocked or old information out there it is hard to find the right place to look. At the end of the day I'm not sure if xdg-desktop-portal, wlroots, or pipewire need to be improved.
I am using sway + wlroots + xdg-desktop-portal-wlr on my system.
- global keybindings (e.g. I would like variations on super+space with extra modifiers to trigger different behaviours in an application launcher, Kupfer)
- remote control (x2x) --- I use this for essentially seamless kvm between different machines driving adjacent monitors
- I have no choice but to use Zoom screen sharing for work
2. Check out Waypipe, it works really well and supports all application types unlike X11 forwarding. It's more like VNC but easy.
3. Last I checked Zoom screen sharing does work via the browser. The only feature I remember missing was screen control. Same experience with MS Teams too.
(Personally I don't think this is a problem: if the attacker can run programs it's game-over already; just replace "su", "sudo", "firefox", or whatnot with your wrapper script which logs stuff, add ~/.local/bin to PATH by frobbing with shell rc, and presto)
Still missing bspwm, lemonbar and dmenu (bmenu/fuzzel, maybe). For those who care, Steam is also a pain point, from what I've heard.
Games may find some benefit from gamescope: https://wiki.archlinux.org/title/Gamescope
On reflection, almost all of my problems are to do with audio; pipewire, and it's interaction with pulse, alsa, jack and so on - being a 0.1% "pro-audio" user I probably have needs that the average Wayland user doesn't see.
It will get better and I will try again.
The pipewire audio stack replaces pulse and jack, it doesn't play well with Jack and Pulse running on the side. It does work well for me (including doing a bit of recording and mixing with Ardour) but, from what I understand, the pro audio use cases, mainly low latency, will be a focus for the version 1.0: https://www.phoronix.com/news/PipeWire-1.0-Release-Plan
Is there a way to streams steam games from a wayland session?
Is it possible to make stacked transparent windows show what is behind them in sway, like we have with i3 and a compositor ?
For this I think I need remote access to a logged out session, which as of my last check is impossible. (It's also poorly supported by gnome on x though)
Maybe I was too literal. The problem isn't executing the reboot command. The problem is logging in remotely to a computer that hasn't been logged into locally since it booted.
In particular the problem is that if I'm going to be remote for an extended period of time I have to ensure that nothing could interrupt the local session, and there's no fix if it does.
Thus, head to an VT, there are good Unicode fonts (Unifont for instance) for basic needs. And with fbpdf2, fbi and mpv (among SDL_VIDEODRIVER set to fbcon/drm) you can spawn framebuffer/DRM based image/video and PDF viewers in a hurry.
p.s: So, all in all, this doesn't exactly make Xorg more dangerous than before, especially w/ rootless X being widely used.
[1] https://news.ycombinator.com/item?id=37608110
However these vulnerabilities are old enough that they would have been useful when X always ran as root.
It's another hole where vulnerability assessment is kinda... wonky.
1: https://xkcd.com/1200/