3 ms·

Wayland has a bad case of security at the cost of usability. They've been adding protocols here and there but there are still obvious things missing. Last time

Wayland has a bad case of security at the cost of usability. They've been adding protocols here and there but there are still obvious things missing. Last time I checked it wasn't even possible to create something like xdotool without relying on some nasty hacks.

Blikkentrekker 6y ago
And on top of that the “security” is useless because any software that runs as one's user account can simply do things such as ptrace the compositor or override the compositor in the PATH with a malicious one or LD_PRELOAD the compositor. As soon as malicious software run as one's own user, then that is that and it can do anything that the user can do. The argument raised against this is that it should be used in conjunction with some measure of a sandboxing technique, and that X11 is “impossible to sandbox”, but X11 sandboxes exist: how they work is a proxy server that sits in between the sandboxed application and the real server that determines what to let through and what not, the sandboxed application thus believes it is the only thing running inside of it's own X11 server, which maps it onto the bigger one. Then the counter argument is that that “doesn't count” and isn't “true sandboxing”, but that is the exact same technique that sandboxes that use Wayland use for say DBus, or PulseAudio, and has always been the standard way of sandboxing such daemons and servers. That's always the highly theoretical argument that comes in to defend these promises that are false on a practical level “it doesn't count”, even though the practical result is the same. All the ways to circumvent Wayland's security “don't count” even though they can all the same be used to compromise it. I am quite convinced after having spoken with many a Wayland developer that nigh none of them actually care about the “security” they so often talk about: they care about a certain theoretical elegance of a “secure system" that only exists in theory but exists in no reality as something that actually has been practically realized. All the actual, effective, real world ways to pierce it are wished away with that they “don't count” as they don't exist in their theoretical dream world.
- jchw 6y ago
  You are forgetting that you actually can sandbox and contain apps. Under X11, doing that and then giving the app access to the display is dangerous. Under Wayland it is not. This matters for Flatpak, Snap, firejail, etc. I have seen multiple such arguments that you can “sandbox” X11 access, with no proof or really bad compromises; I don’t believe it.
  - Blikkentrekker 6y ago
    > You are forgetting that you actually can sandbox and contain apps. Under X11, doing that and then giving the app access to the display is dangerous. Under Wayland it is not. This matters for Flatpak, Snap, firejail, etc. I addressed this in my very post and forgot no such thing. Firejail can and does sandbox X11. > I have seen multiple such arguments that you can “sandbox” X11 access, with no proof or really bad compromises; I don’t believe it. How is there no proof? it exists in Firejail at this moment.. The compromises are those which one has to live with on Wayland per sē: naturally things that need access don't work, and Nvidia card acceleration does not work. https://firejail.wordpress.com/documentation-2/x11-guide/ https://firejail.wordpress.com/documentation-2/x11-guide/ This existed and happened long ere Wayland was even conceived.
    - jchw 6y ago
      What Firejail supports is nested X servers, which are complicated and often buggy. Last I checked Firejail itself only recommended using X11 sandboxing when dealing with hostile situations. I consider having to use a nested X server, even one capable of forwarding, a huge compromise based on my experience with it. Anyway, that did not exist before Wayland was even conceived. First of all, hardware acceleration in Xpra has been a relatively rocky story for a long time. Second of all, Firejail didn’t support using it until 2016. If you want to keep buying borderline Linux-incompatible video cards and running an unmaintained display server, by all means try to jam a security model onto an inherently insecure client-server system to help justify it. As cold as it may be, the world will happily leave you behind. And if you don’t believe me, just keep waiting. Lots of people thought Macromedia Flash would stick around forever, too.
pmoriarty 6y ago
"Last time I checked it wasn't even possible to create something like xdotool without relying on some nasty hacks." Well, there's ydotool for Wayland, but unfortunately it doesn't even have half the features of xdotool, and probably won't be improving much any time soon, since its README says "Since Jun, 2019, I have little time to maintain this project". At this rate, it'll probably take another 10 or 20 years for Wayland to catch up to all the already-existing useful features of X.

Blikkentrekker 6y ago

And on top of that the “security” is useless because any software that runs as one's user account can simply do things such as ptrace the compositor or override the compositor in the PATH with a malicious one or LD_PRELOAD the compositor. As soon as malicious software run as one's own user, then that is that and it can do anything that the user can do. The argument raised against this is that it should be used in conjunction with some measure of a sandboxing technique, and that X11 is “impossible to sandbox”, but X11 sandboxes exist: how they work is a proxy server that sits in between the sandboxed application and the real server that determines what to let through and what not, the sandboxed application thus believes it is the only thing running inside of it's own X11 server, which maps it onto the bigger one. Then the counter argument is that that “doesn't count” and isn't “true sandboxing”, but that is the exact same technique that sandboxes that use Wayland use for say DBus, or PulseAudio, and has always been the standard way of sandboxing such daemons and servers. That's always the highly theoretical argument that comes in to defend these promises that are false on a practical level “it doesn't count”, even though the practical result is the same. All the ways to circumvent Wayland's security “don't count” even though they can all the same be used to compromise it. I am quite convinced after having spoken with many a Wayland developer that nigh none of them actually care about the “security” they so often talk about: they care about a certain theoretical elegance of a “secure system" that only exists in theory but exists in no reality as something that actually has been practically realized. All the actual, effective, real world ways to pierce it are wished away with that they “don't count” as they don't exist in their theoretical dream world.

jchw 6y ago
You are forgetting that you actually can sandbox and contain apps. Under X11, doing that and then giving the app access to the display is dangerous. Under Wayland it is not. This matters for Flatpak, Snap, firejail, etc. I have seen multiple such arguments that you can “sandbox” X11 access, with no proof or really bad compromises; I don’t believe it.
- Blikkentrekker 6y ago
  > You are forgetting that you actually can sandbox and contain apps. Under X11, doing that and then giving the app access to the display is dangerous. Under Wayland it is not. This matters for Flatpak, Snap, firejail, etc. I addressed this in my very post and forgot no such thing. Firejail can and does sandbox X11. > I have seen multiple such arguments that you can “sandbox” X11 access, with no proof or really bad compromises; I don’t believe it. How is there no proof? it exists in Firejail at this moment.. The compromises are those which one has to live with on Wayland per sē: naturally things that need access don't work, and Nvidia card acceleration does not work. https://firejail.wordpress.com/documentation-2/x11-guide/ https://firejail.wordpress.com/documentation-2/x11-guide/ This existed and happened long ere Wayland was even conceived.
  - jchw 6y ago
    What Firejail supports is nested X servers, which are complicated and often buggy. Last I checked Firejail itself only recommended using X11 sandboxing when dealing with hostile situations. I consider having to use a nested X server, even one capable of forwarding, a huge compromise based on my experience with it. Anyway, that did not exist before Wayland was even conceived. First of all, hardware acceleration in Xpra has been a relatively rocky story for a long time. Second of all, Firejail didn’t support using it until 2016. If you want to keep buying borderline Linux-incompatible video cards and running an unmaintained display server, by all means try to jam a security model onto an inherently insecure client-server system to help justify it. As cold as it may be, the world will happily leave you behind. And if you don’t believe me, just keep waiting. Lots of people thought Macromedia Flash would stick around forever, too.

pmoriarty 6y ago

"Last time I checked it wasn't even possible to create something like xdotool without relying on some nasty hacks." Well, there's ydotool for Wayland, but unfortunately it doesn't even have half the features of xdotool, and probably won't be improving much any time soon, since its README says "Since Jun, 2019, I have little time to maintain this project". At this rate, it'll probably take another 10 or 20 years for Wayland to catch up to all the already-existing useful features of X.