4 ms·

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.

by jude- 6y ago

kaba0 6y 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- 6y 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 6y 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- 6y 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 6y 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- 6y 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...
        taway098123 6y ago
        It's not wrong, it's not FUD, and that doesn't change anything. The only working plugin is the SELinux one. If you can't use that, you have to rebuild an entire new security architecture... which is what they had to do in Wayland anyway. XACE isn't really built for anything besides MAC either, so it's inadequate for doing anything that isn't an LSM. It also has a problem where new hooks need to be added for every new X extension, and that didn't happen so now it's outdated. In Wayland that entire concept was replaced with a single API function to do generic traffic filtering. It's also outside the scope of a desktop environment or window manager to ship plugins to the X server. Hence another reason why they had to go with a new protocol that makes it easier to implement their own server...
        jude- 6y ago
        > The only working plugin is the SELinux one. If you can't use that, you have to rebuild an entire new security architecture I stopped reading at this point. If you're not going to read the documentation, then you can kindly go crawl back under your rock on /r/linuxmasterrace.

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.

by jude- 6y 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 6y 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- 6y 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 6y 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- 6y 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 6y 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- 6y 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...
        taway098123 6y ago
        It's not wrong, it's not FUD, and that doesn't change anything. The only working plugin is the SELinux one. If you can't use that, you have to rebuild an entire new security architecture... which is what they had to do in Wayland anyway. XACE isn't really built for anything besides MAC either, so it's inadequate for doing anything that isn't an LSM. It also has a problem where new hooks need to be added for every new X extension, and that didn't happen so now it's outdated. In Wayland that entire concept was replaced with a single API function to do generic traffic filtering. It's also outside the scope of a desktop environment or window manager to ship plugins to the X server. Hence another reason why they had to go with a new protocol that makes it easier to implement their own server...
        jude- 6y ago
        > The only working plugin is the SELinux one. If you can't use that, you have to rebuild an entire new security architecture I stopped reading at this point. If you're not going to read the documentation, then you can kindly go crawl back under your rock on /r/linuxmasterrace.