Quote Originally Posted by secret resistor View Post
As I said the xinput binary is only used as a proof of concept, so it is not that relevant. What you need to block is the underlying calls or requests to the X server, otherwise you are not preventing the keylogger from obtaining the information. All your examples seem to be about running new processes (correct me if I'm wrong) which is not required for an exploited application to be recording keystrokes. And if the application is already allowed to make arbitrary HTTP requests (as firefox would be) than there is nothing stopping it from reporting the keystrokes to the attacker.

Yes, I realise that this may seem a bit offtopic but I still think it is relevant to the question of how to protect against a keylogger.
As I understand it, because the aa Firefox profile has this:

Code:
/usr/ r,
  /usr/** r,
it can't run XInput. However, if the malware gets out of FF and onto the computer, it's free to do so, because it is unconstrained by Apparmor. The problem for the malware, as I said before, is:

1) How it gets onto the computer in the first place
2) How it launches

Because aa stops it from getting to anywhere it can self-start, it would have to be extra crafty or trick the user into running it. And that last option is the most likely, since it only depends on one vulnerability.