keylog

There is no way to fix it. Also, X11 has several ways of writing keyloggers to get around input locks. I've written one here https://github.com/magcius/keylog

Reminder that this breaks basic features like copy/paste, drag-and-drop, and a lot of applications that spawn helper applications and expect them to be on the same display. There is a reason that the general Linux desktop camp is not adopting solutions like this and instead preferring Wayland, and that's that these systems can never be production ready and support the featureset that traditional X11 can support. Also, I tested my keylogger [0] on this setup, and it still got through. Oops. They're proxying through XRecord and XTest it seems. https://github.com/magcius/keylog

But why can he vouch that libX11 is any more secure? The library that runs complex input method code on every key-press, that has had CVEs in it? [0] [1] [0] https://cgit.freedesktop.org/xorg/lib/libX11/tree/modules/im... [1] https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-20... Not to mention that I can still write a keylogger that bypasses jwz's xscreensaver. [2] [2] https://github.com/magcius/keylog

This is not sandboxing. Quite the opposite, this gives the apps root access: First of all, X11 is completely unsecure, the "sandboxed" app has full access to every other X11 client. Thus, its very easy to write a simple X app that looks for say a terminal window and injects key events (say using Xtest extension) in it to type whatever it wants. Here is another example that sniffs the key events, including when you unlock the lock screen: https://github.com/magcius/keylog Secondly, if you have docker access you have root access. You can easily run something like: docker run -v /:/tmp ubuntu rm -rf /tmp/* Which will remove all the files on your system.

> I believe this should work: https://github.com/magcius/keylog Interesting. Only works if the RECORD extension is enabled, however. Seems some distros have that off by default and have for years.

> Is this true? Can you provide a proof of concept that can attack xscreensaver in this way? I believe this should work: https://github.com/magcius/keylog > What is bad about letting an app talk to alsa if it needs audio? In general, audio output is not really a problem. However, input is much more problematic. For instance, your app could listen on your microphones and send the data over the network. Permissions on the audio device doesn't work here, especially considering that such permissions are per-user, not per-app. Overall the security model in unix is pretty shit for the desktop. Its all about protecting root or other users from the user. However, if I'm on a single user laptop that is not overly interesting. The much more interesting part is protecting the user from the system. For instance by being able to run a game without it