It is 100% possible. For ttys/ptys (text mode), the easiest way is to add a shim to /bin/{ba,da,a}sh (e.g., a second .code segment, R-X) and change the entry point (much as an ELF virus would). Barring access to that in this case, one can modify ~/.profile or ~/.bashrc (etc.) to, as a very simple hypothetical model:
exec ~/.malicious_programme
which may load dynamic shared object code to hide the malicious programme in question (example: allow .profile read and modification, but hide the line. And/or hide the programme.)
One may then use the UNIX98 pty(7) system or even simply pipe(2) to record all input in a forked shell, assuming the fd is not marked FD_CLOEXEC, and even change user input to the shell.
In X11, although kdm/gdm/xdm run as setuid root (or the equivalent in capabilities [see setcap(8)] or whatever security model you're using if non-default), things become more complicated, obviously. If one can elevate privileges? iopl(2) or ioperm(2) makes life quite easy with direct access to 0x60 / 0x64 keyboard ports on x86. Since we're assuming you can't, we must look for an alternative route. I know of several, but I am not entirely sure you want a dissertation on how it's possible and the interfaces involved.
Suffice to say, ring 3, non-superuser trojans are quite possible on *nix, in spite of process isolation, as a result of various issues (particularly with X) that has added features for user-mode daemons to provide, e.g., text-to-speech support for all apps w/o compromising the system's security. I already outlined one that works analogously to ttysnoops (which is long past its expiry date), and it does not require root. I have sample code for this case (which would include inside terminals in X), but I have not as-yet published it. If you want more information, please feel free to contact me.
I believe this can be done at the X level easily. Just think about the programs with global shortcuts. – Denis Nikolaenko – 2011-09-05T19:53:52.577
To prevent X window system keyloggers, you need to implement SELinux for X. To my knowledge, no wide spread Linux distribution does that out of the box. http://www.nsa.gov/research/_files/selinux/papers/x11/t1.shtml
– Denis Nikolaenko – 2011-09-05T20:05:37.353Do you know of any actual working examples? Without seeing it work first hand, I remain skeptical. And without knowing that it's really possible for a keylogger to get installed without sudo/root privileges, it's not worth it to deal with the complexity of setting up AppArmor or SELinux to defend against it. – Mike Rowave – 2011-09-06T01:44:30.787
1http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html – Denis Nikolaenko – 2011-09-11T18:00:55.143
I see that no one has submitted a working proof of concept yet. On a properly configured Linux system where device permissions are properly set, the methods to install a keylogger will require either authorized privilege escalation via su/sudo or unauthorized privilege escalation via a vulnerability. – Xenoactive – 2011-09-19T20:18:59.570
3Please summarize the important points of the video in your answer. It could be deleted, or the server could become unavailable. (Yes, as I'm posting, Youtube is down.) It's also rather rude to require that visitors watch a video to figure out what your question is about. – Gilles 'SO- stop being evil' – 2013-11-18T23:27:18.767