A comment on this answer states:

The whole linux desktop provides very little protection against bad processes running as the user. A bad process could just watch the keyboard input and wait for the user to run a command as sudo. The bad process now has root without ever being known to the user.

Frankly, this scares me - I was under the impression that sudo <command> would only give elevated permissions to run that command, and this method of strict permission management was what made linux much more secure than Windows. I didn't think that sudo could be "intercepted".

Are "bad processes" capable of watching the keyboard to obtain root access? If so, how would a process grant itself those permissions when they are for another process? An example of a bad process that could do this along with possible countermeasures would be really appreciated.


1 Answer 1


You're right that sudo only grants elevated privileges to the command you run with it.

What the commenter is referring to is that running processes in a Linux desktop session can watch the keystrokes on that desktop session without you knowing. So if you open a terminal window on your desktop, type sudo <some command>, and enter your password at the prompt, a malicious program could be keeping track of the keystrokes you typed in and then silently pass the captured password to its own instance of sudo to run whatever command it likes as root.

As a simple (non-malicious) example, the program screenkey is able to watch the keys you type without needing root privileges. Also, I would bet that global hotkeys (e.g. the Super key) work in much the same way.

This sounds pretty scary. As for possible countermeasures, I don't really know if there are any once the "bad process" is running on your system. So, all you can really do are preventative measures, like:

  • Practice good internet hygiene, i.e. don't download random untrusted executables from the Internet
  • Be careful which files you set the execute bit (chmod +x) on
  • If you have to run an untrusted executable, run it with the lowest possible privileges
    (e.g. sudo -u nobody <untrusted program> will run <untrusted program> as nobody, which has no access to your user's X11 server and therefore can't watch your keystrokes)
  • 1
    There is a real way to mitigate this, which is to log in directly as root when you need it using a different TTY.
    – forest
    Commented May 10, 2019 at 5:56
  • @forest: you don't necessarily need to login directly as root, you can run sudo from another TTY (not from inside the compromised X session) and you make sure that your login shell doesn't load any rc/profile script from your home directory that you hadn't verified, then an X session key logger won't be able to intercept your key presses.
    – Lie Ryan
    Commented May 10, 2019 at 9:34
  • Also, Wayland is a thing, and doesn't allow this exact attack anymore. Commented May 10, 2019 at 12:50
  • @LieRyan Unfortunately it's quite difficult to ensure your shell doesn't load anything that you haven't verified, since they access a lot of potential files. But with enough effort, this could certainly work.
    – forest
    Commented May 11, 2019 at 0:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .