3 ms·

You're arguing against Wayland, but for a more secure Linux desktop? I recommend you spend more time getting to know the X11 protocol then, because it has plent

You're arguing against Wayland, but for a more secure Linux desktop? I recommend you spend more time getting to know the X11 protocol then, because it has plenty of design decisions that simply cannot be secured. The same people who used to develop XFree86 designed Wayland to fix things that could not be fixed in the scope of X11.

wmanley 2y ago
> the X11 protocol [...] has plenty of design decisions that simply cannot be secured. I've been hearing this for over a decade now. I don't get it. Just because xorg currently makes different clients aware of each other and broadcasts keypresses and mouse movements to all clients and allows screen capturing doesn't mean it has to. You could essentially give every application the impression that they are the only thing running. It might seem difficult to implement, but compare it to the effort that has gone into wayland across the whole ecosystem. Maybe that was the point - motivating people to work on X was too difficult, and the wayland approach manages to diffuse the work out to more people. I was really bullish on Wayland 10 years ago. Not so much any more. In retrospect it seems like a failure in technical leadership.
- uecker 2y ago
  X always had the capability to isolate clients, but it is not used it would need some work which nobody does because of Wayland.
  - welterde 2y ago
    Some aspects of the client isolation are used by default when doing X11 forwarding via SSH. A remote keylogger will not work for instance.
- yencabulator 2y ago
  It'll be challenging to even figure out which one of the things connecting to $DISPLAY is the real window manager. Good luck on your lonely[1] journey! [1]: The people who actually developed Xorg are now working on various Wayland-related things.
  - wmanley 2y ago
    > It'll be challenging to even figure out which one of the things connecting to $DISPLAY is the real window manager. I suspect it would be less challenging than writing a whole new wayland server. Off the top of my head, I'd use a separate abstract domain socket for the window manager including some UUID, and then pass that to the window manager when launching it. You could create these sockets on demand - one for each security context. On linux typically a different security contexts will either have different UIDs - in which case filesystem permissions would be sufficient - or they have different mount namespaces - in which case you make different sockets visible in different namespaces. For SSH forwarding you could have SSH ask the X server for a new socket for forwarding purposes - so remote clients can't snoop on local clients. > Good luck on your lonely[1] journey! > > [1]: The people who actually developed Xorg are now working on various Wayland-related things. This is what I mean by a failure of technical leadership.
    - tankenmate 2y ago
      "You could create these sockets on demand - one for each security context. On linux typically a different security contexts will either have different UIDs - in which case filesystem permissions would be sufficient - or they have different mount namespaces - in which case you make different sockets visible in different namespaces." This is reminiscent of how Trusted Solaris[0] implements Mandatory Access Control (MAC) a la Orange Book[1]. [0] https://www.oracle.com/technetwork/server-storage/solaris10/overview/ds-ts8-150124.pdf https://www.oracle.com/technetwork/server-storage/solaris10/... [1] https://public.milcyber.org/activities/magazine/articles/2021/renda-the-orange-book https://public.milcyber.org/activities/magazine/articles/202...
    - welterde 2y ago
      > For SSH forwarding you could have SSH ask the X server for a new socket for forwarding purposes - so remote clients can't snoop on local clients. SSH pretty much already does this. Per default (using -X) X11 forwarding is in untrusted mode, which makes certain unsafe X11 extensions unavailable. So remote clients already cannot snoop the whole keyboard input.
    - 2y ago
- fsflover 2y ago
  > You could essentially give every application the impression that they are the only thing running. > It might seem difficult to implement This is exactly what OS did (my daily driver): https://forum.qubes-os.org/t/inter-vm-keyboard-isolation/31537 https://forum.qubes-os.org/t/inter-vm-keyboard-isolation/315...

wmanley 2y ago

> the X11 protocol [...] has plenty of design decisions that simply cannot be secured. I've been hearing this for over a decade now. I don't get it. Just because xorg currently makes different clients aware of each other and broadcasts keypresses and mouse movements to all clients and allows screen capturing doesn't mean it has to. You could essentially give every application the impression that they are the only thing running. It might seem difficult to implement, but compare it to the effort that has gone into wayland across the whole ecosystem. Maybe that was the point - motivating people to work on X was too difficult, and the wayland approach manages to diffuse the work out to more people. I was really bullish on Wayland 10 years ago. Not so much any more. In retrospect it seems like a failure in technical leadership.

uecker 2y ago
X always had the capability to isolate clients, but it is not used it would need some work which nobody does because of Wayland.
- welterde 2y ago
  Some aspects of the client isolation are used by default when doing X11 forwarding via SSH. A remote keylogger will not work for instance.
yencabulator 2y ago
It'll be challenging to even figure out which one of the things connecting to $DISPLAY is the real window manager. Good luck on your lonely[1] journey! [1]: The people who actually developed Xorg are now working on various Wayland-related things.
- wmanley 2y ago
  > It'll be challenging to even figure out which one of the things connecting to $DISPLAY is the real window manager. I suspect it would be less challenging than writing a whole new wayland server. Off the top of my head, I'd use a separate abstract domain socket for the window manager including some UUID, and then pass that to the window manager when launching it. You could create these sockets on demand - one for each security context. On linux typically a different security contexts will either have different UIDs - in which case filesystem permissions would be sufficient - or they have different mount namespaces - in which case you make different sockets visible in different namespaces. For SSH forwarding you could have SSH ask the X server for a new socket for forwarding purposes - so remote clients can't snoop on local clients. > Good luck on your lonely[1] journey! > > [1]: The people who actually developed Xorg are now working on various Wayland-related things. This is what I mean by a failure of technical leadership.
  - tankenmate 2y ago
    "You could create these sockets on demand - one for each security context. On linux typically a different security contexts will either have different UIDs - in which case filesystem permissions would be sufficient - or they have different mount namespaces - in which case you make different sockets visible in different namespaces." This is reminiscent of how Trusted Solaris[0] implements Mandatory Access Control (MAC) a la Orange Book[1]. [0] https://www.oracle.com/technetwork/server-storage/solaris10/overview/ds-ts8-150124.pdf https://www.oracle.com/technetwork/server-storage/solaris10/... [1] https://public.milcyber.org/activities/magazine/articles/2021/renda-the-orange-book https://public.milcyber.org/activities/magazine/articles/202...
  - welterde 2y ago
    > For SSH forwarding you could have SSH ask the X server for a new socket for forwarding purposes - so remote clients can't snoop on local clients. SSH pretty much already does this. Per default (using -X) X11 forwarding is in untrusted mode, which makes certain unsafe X11 extensions unavailable. So remote clients already cannot snoop the whole keyboard input.
  - 2y ago
fsflover 2y ago
> You could essentially give every application the impression that they are the only thing running. > It might seem difficult to implement This is exactly what OS did (my daily driver): https://forum.qubes-os.org/t/inter-vm-keyboard-isolation/31537 https://forum.qubes-os.org/t/inter-vm-keyboard-isolation/315...