4 ms·
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/*
by 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 agoWhat 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 agoX 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 agoXACE 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 agoWrong. 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 agoIt'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.
- taway098123 6y agoI was familiar with that documentation around 10 years ago, please stop making these assumptions and please stop dismissing what I have to say. The documentation is irrelevant, I'm talking about the server source code. There is one real plugin implementation there that uses SELinux. That's it. There is currently no other real way to use XACE, it's otherwise totally useless to end users. Yes people could develop new plugins that integrate with some other security mechanism, but they haven't, in part because the hooks are so out of date, and in part because, you know, that requires building another security mechanism. The access hooks are not a security mechanism, they allow you to integrate with some external MAC.