4 ms·

X11 is a security nightmare. It is absolutely broken enough to justify a huge change.

michaelmrose 5y ago
Installing random software off the internet or from a market that developers have direct access to poison is a security nightmare that isn't much fixed by wayland.
- kaba0 5y ago
  Allowing smoking between barrels of gunpowder is different than in an open space. Wayland is a necessary part of security, but not sufficient.
  - michaelmrose 5y ago
    Unless you are using different vms for isolation it's all open barrels of gunpowder all the time.
    - kaba0 5y ago
      I agree with you in general, but even if you use jailed apps in X, they can keylog. It can be solved with nested X sessions, but that would only add yet another hacky patch.
  - jude- 5y ago
    It's security theater. If I can run a process on your machine under your user account, you can bet I can keylog you, X11 or no.
    - kaba0 5y ago
      Try it. You can’t unless you’ve found some exploit in a given wayland compositor. Linux only grants permission to keyboard/mouse events to root or to display “owner”, which is the one who requested it on a given tty.
      - jude- 5y ago
        Here are a few ways off the top of my head that don't require exploiting Wayland or gaining access to the `input` group (or whatever group owns the /dev/input/* events), using nothing more than a local shell under your user account: * Using ptrace(2) to hook into your running processes and grabbing key data that way * Adding a LD_PRELOAD around your application launcher (via your .bashrc or some other auto-exec script) to have it intercept key events for your application * Downloading and mounting a FUSE filesystem image with the /dev/input device nodes owned by your user ID instead of root. * Use one of the multitude of privilege-escalation CVEs on the Linux desktop to gain root, and keylog you that way [1]. Come back when you understand the problem. [1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=linux+privilege+scalation https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=linux+privi...
        kaba0 5y ago
        What is not clear about necessary but not sufficient? Of course sandboxing is necessary, but graphics is a deliberate hole in a sandbox. If that hole is unsecure, the whole thing is. How does X help here?
        jude- 5y ago
        X already solves this particular input hole with the XACE extension. No need to replace the whole graphics stack when the X server is already capable of addressing this issue.
        taway098123 5y ago
        XACE doesn't solve it. As mentioned elsewhere, that's dependent on SELinux. The idea with Wayland is to make things more secure everywhere, and not just on systems that have a particular LSM.
        jude- 5y ago
        Wrong. XACE is independent of SELinux and LSMs. It's just a protocol for writing plugins to X servers that filter which events X clients can see. That there exist SELinux plugins does not mean that XACE itself depends on it. Like, try reading the actual documentation instead of regurgitating FUD: https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/Xserver/XACE-Spec.html https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/Xserv...

Installing random software off the internet or from a market that developers have direct access to poison is a security nightmare that isn't much fixed by wayland.

kaba0 5y ago
Allowing smoking between barrels of gunpowder is different than in an open space. Wayland is a necessary part of security, but not sufficient.
- michaelmrose 5y ago
  Unless you are using different vms for isolation it's all open barrels of gunpowder all the time.
  - kaba0 5y ago
    I agree with you in general, but even if you use jailed apps in X, they can keylog. It can be solved with nested X sessions, but that would only add yet another hacky patch.
- jude- 5y ago
  It's security theater. If I can run a process on your machine under your user account, you can bet I can keylog you, X11 or no.
  - kaba0 5y ago
    Try it. You can’t unless you’ve found some exploit in a given wayland compositor. Linux only grants permission to keyboard/mouse events to root or to display “owner”, which is the one who requested it on a given tty.
    - jude- 5y ago
      Here are a few ways off the top of my head that don't require exploiting Wayland or gaining access to the `input` group (or whatever group owns the /dev/input/* events), using nothing more than a local shell under your user account: * Using ptrace(2) to hook into your running processes and grabbing key data that way * Adding a LD_PRELOAD around your application launcher (via your .bashrc or some other auto-exec script) to have it intercept key events for your application * Downloading and mounting a FUSE filesystem image with the /dev/input device nodes owned by your user ID instead of root. * Use one of the multitude of privilege-escalation CVEs on the Linux desktop to gain root, and keylog you that way [1]. Come back when you understand the problem. [1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=linux+privilege+scalation https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=linux+privi...
      - kaba0 5y ago
        What is not clear about necessary but not sufficient? Of course sandboxing is necessary, but graphics is a deliberate hole in a sandbox. If that hole is unsecure, the whole thing is. How does X help here?
        jude- 5y ago
        X already solves this particular input hole with the XACE extension. No need to replace the whole graphics stack when the X server is already capable of addressing this issue.
        taway098123 5y ago
        XACE doesn't solve it. As mentioned elsewhere, that's dependent on SELinux. The idea with Wayland is to make things more secure everywhere, and not just on systems that have a particular LSM.
        jude- 5y ago
        Wrong. XACE is independent of SELinux and LSMs. It's just a protocol for writing plugins to X servers that filter which events X clients can see. That there exist SELinux plugins does not mean that XACE itself depends on it. Like, try reading the actual documentation instead of regurgitating FUD: https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/Xserver/XACE-Spec.html https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/Xserv...