Actually, I'd like to ask 3 questions. But since they are very related, I'll ask them all here. I use Ubuntu 12.04.4.

Situation 1: I use Terminator, in one of its terminals I launch sudo iotop (because it doesn't work without root access). Question is: can a malware gain root privileges via a process that is run with use of sudo , and how?

Situation 2: I open tty1 (Ctrl+Alt+F1) and type sudo -s there, thus gaining the root privileges. Without exiting this sudo shell, I may go back to my graphical interface (Ctrl+Alt+F7) and work as an unprivileged user. Question is: can a malware abuse this sudo root shell in tty1 console to gain root privileges?

Situation 3: I run sudo -s in a Gnome Terminal. Can this shell be abused by a malware to gain root access? Here, I have a presumption, that it can abuse some input functions to activate terminal's window and type a command in terminal, but not sure.


3 Answers 3


It depends on where the malware resides. Let's assume you mean : some program running as your user and wanting to get privileges.

Really short X security primer

First, you have to be aware that X does some access control but does not isolate between connected clients. Every client connected to your desktop can query the server to obtain information about any other X client and interact with it.

For example, if you run Skype (or whatever program, open-source or not) on your desktop, it can spy activity : list windows, their titles, take screenshots, log keypresses, even (with some graphical toolkits) figure out the structure of what it's currently displaying. So in theory it can locate if you have a terminal with a root shell opened, send keypresses events to type something there (though not all terminal emulators obey these).

In practice simulating keypresses may be noticed by you (you see that something happened, or maybe the program could just close the window after doing the job to hide it), while plain keylogging is invisible (especially) if the program is authorized to communicate with the outside world through an encrypted connection (instant messaging, audio and video programs for example, that includes Skype, Google Talk, Flash and other plugins).

Reference: The Invisible Things Lab's blog: The Linux Security Circus: On GUI isolation

Answers to your questions.

In situation 1, you basically trust iotop but I guess that's not your point. Let's imagine a malware connected to your desktop or running as your user. It could try to trick iotop into doing something nasty (by simulating keypresses, etc.) but it would probable be ineffective.

In situation 2, the shell is separated from X, so it's better security-wise. You have to know that one program running with your user account can write on a Linux virtual console where you're logged in, but it's only inserting characters on the screen, not process activity. AFAIK you can't trick a program into actually typing something into another Linux virtual console.

Situation 3 is what's explained above. A program could notice that, type some commands and try to hide the fact.

If you're really concerned, you are probably interested in security by isolation and Qubes.

  • Aha! So me trying not to use sudo -s in GUI terminals and using it in console instead is a good idea, right?
    – Highstaker
    Jan 30, 2015 at 22:30
  • @Highstaker: In theory, yes, in the precise sense that AFAIK sudo -s in a console opens less attack surface than in an X terminal. In practice, it depends on how (in)convenient it is to you, what remains of the attack surface, and what is at stake. It's up to you. Jan 31, 2015 at 7:17

Seeing some answer in another site thinks not using the root account increases security, I'm posting this.

With the default timeout settings, there is an easy way to gain root privileges by adding this line in .bashrc:

trap 'sudo -S touch /hacked </dev/null 2>/dev/null' debug

It will create a file hacked in the root directory once the user has used sudo.

A complete hack could also modify the trap command to prevent the user knowing this, and hide those modifications by modifying set, declare, command, type, etc. Another option is to modify sudo itself.

In theory a program can kill your panel and desktop, replacing them with modified versions where every entry to sudo or gksu, etc, or a monitoring program, is replaced with something else. The above code just made it easier. There can be workarounds by modifying sudo in some ways, but at least I don't think the sudo password can be used for security purposes in the current version.


An application running as SUDO is going to be running in privileged memory and an application that doesn't already run as SUDO is going to be unable to access the code.

It might be possible to do some kind of an injection attack against the application if it is poorly coded and uses some other mechanism to expose itself outside the privileged space, but it would be non-trivial to do so and would have to be specific to that application.

You must log in to answer this question.

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