I often log into X as normal user (of course), open terminal and switch to root:

su -

I have then a terminal owned by user but effectively with root privileges.

Are there any security issues in this situation?

Can a malware/exploit running under normal user potentially get access to the root console (possibly by exploiting some bug in X server?

Is this less safe, than if I had switched to text console (Ctrl+Alt+F1) and logged in as root directly ?


I have to enter the root password every time I switch to root using su -

  • I think you forgot to mention something here, how can you switch to the root user using su without entering the root password?
    – Ulkoma
    Commented Jan 11, 2015 at 12:52
  • @Ulkoma - no, I have to enter the password for root every time I use su -. Commented Jan 11, 2015 at 12:59
  • This means any malware running under normal user will have to know the password in order to become root using su. Also any malware running under normal user can exploit a privileges escalation vulnerability in order to become a root but this has nothing to do with the su command or X server
    – Ulkoma
    Commented Jan 11, 2015 at 13:16
  • @Ulkoma - so there is no way for a malware to "attach" to the existing terminal (which is owned by user, not root) ? Commented Jan 11, 2015 at 13:21
  • I am not sure what "attach" means here but it is very possible for the malware to act as a keylogger and record the password that you enter after su, this is a known problem with X server superuser.com/questions/301646/…
    – Ulkoma
    Commented Jan 11, 2015 at 13:26

5 Answers 5


Yes, it is less safe than if you switched to text console and log in as root directly.

Proof 1:

If you are logged in as root in a terminal, another process can send commands to that terminal.

Simple proof of concept:

  1. Open a terminal, place in in the top left corner of the screen and switch to root.
  2. Open a second terminal that does not overlap the first and type:

$ xdotool mousemove 100 100 click 1 && xdotool key l && xdotool key s && xdotool key KP_Enter


Proof 2:

xinput can read all keyboard strokes


$ xinput list

to identify the id of your keyboard and

$ xinput test id

to see which keystrokes are pressed. This will also display the keystrokes from the su terminal and reveal your password.

xinput man page

  • what is the xdotool code supposed to do? It does not seem to have any effect on my machine. Could you please elaborate on that? Commented Jan 20, 2015 at 8:27
  • It issues the ls command. Do you have the xdotool installed? Commented Jan 20, 2015 at 10:08
  • "xdotool mousemove 100 100 click 1" - moves the mouse at the 100.100 coordinates on your screen( where you should have an open terminal with root privileges) and simulates a mouse click there (to focus the window) and "xdotool key l && xdotool key s && xdotool key KP_Enter" issues the ls command by sending each each key. This is just a demo to show that a process running as a normal user can send key presses to the terminal running as root.
    – Dinu
    Commented Jan 20, 2015 at 11:23

If your low privileged user has run malware under their privileges it is possible for that malware to have changed your users path and created a different "su" executable. When you open a terminal as your low privileged user the evil su is now first on your path so when it prompts you for your password you have lost control of the password.

This would be avoided if you switched to a text-console and logged in as root. However if you switch to a text-console login as yourself and su to root, your in the same situation as doing this from X. Note it may be possible for a malware to intercept the ctrl+alt+F1 and trick you into entering username and password but I suspect this would be much harder and may require more privileges.

Also note that local privilege escalations are very common, so once malware is running as any user, it is possible that that malware is able to get root though privilege escalations.


I am not familliar with linux internals to a great extent, so take this answer with a grain of salt.

When you log into X server as a normal user, all of the processes spawned are of the privileges granted to that user. The processes have restricted access to the system, the extent of which is enforced by operating system configuration, but are free to interact with other user processes. Because of this, the process memory adress space is accessable, and most likely writable by all other processes owned by this user. When you elevate your privileges by running the su program, the new subprocess, thread, whatever it may be, is launched by the parent process running as the normal user.

With this in mind, it is possible to imagine a scenario where an injection of code is done into this parent process, in order to get access to the internal memory space of that victim process. If so, it is theoreticly possible to intercept the session and privilege "token" to obtain root access.

I can see this done in two different ways: - Set a hook for a launch of su program and divert the flow to elevate several processes, instead of just the desired one. - Intercept an active session, and inject a request to spawn or elevate a different process.

Both of these scenarios would require arbitrary code execution on a victim machine, so it would be a later stage of the compromise. It might make a difference if you run X or not, in a sence that a correct process to inject into might be harder to know about, rather than the default bash.

In any case, I would think that it is feasable to perform such an attack, but the code to do so would have to be quite targeted, and unless you are a victim of an APT campaign, the chances of someone rooting your box by stealing your 'su -' comand are close to none.

I have no practical knowledge of how to pull of such a stunt on linux, so if I am wrong about the above points, feel free to correct me.


Using root (in terminal) in a user-level account might give you data insecure that may result in malware exploit in cross terminal exploitation. So, basically just use full root access.

Switching to root in a user-level account is quite a harsh thing to do. So, it's better if you switch to root every time you log in simply by ->

First edit the file /etc/login.defs and uncomment the following line (remove the '#' in front):

NO_PASSWORD_CONSOLE tty1:tty2:tty3:tty4:tty5:tty6

You have to do that so it doesn't ask for a password once you log in.

Second, edit /etc/inittab. This file is a bit compicated so it helps if you're familiar with it a little, but if you're not just work on the following line:

c1:12345:respawn:/sbin/agetty 38400 tty1 linux

You want to tell the agetty program to execute an auto login program (we will write this below). Replace the line above with the follwing:

c1:12345:respawn:/sbin/agetty -n -l /usr/sbin/autologin 38400 tty1 linux

The /usr/sbin/autologin program doesn't come with your system, you have to write it and compile it yourself, but it's pretty easy. First create an empty text file and add the following contents to it:

int main() 
  execlp( "login", "login", "-f", "shafiq", 0);

Replace shafiq with the name of the user you want to log in automatically and save the file as autologin.c.

Then compile the program like this (you have to be root for that to work):

cc autologin.c -o /usr/sbin/autologin

And that's it. When your machine finishes booting it will execute the autologin program which will log in as the user you specified in autologin.c and because you edited /etc/login.defs it won't ask for a password.

Now to execute a program after it logs in just edit .bash_profile in the user's home directory (create the file if it doesn't exist) and append the command you want to run at the end of that file, for example this is my .bash_profile, all it does is run pico:


And if you feel unsafe of doing this, try to encrypt your BIOS during boot up. And let's see if anyone can open your device even at the very early booting up stage of whatever device you're using.



Yes it would be safer to open up a new console and login as root. When you use su - you are piping a root session to you normal user session. If there was an attacker that had shell access to your normal account he could hijack that session you have with root. He might not be able to hijack X session however he could hijack the connection between normal user and root user.

  • by saying "open up a new console and login as root", you mean open a new console in X as root (without su -)? How would I do it? Commented Jan 20, 2015 at 8:25
  • Yes you could do that by using Ctrl+Alt+F1 as you stated above. When you use Ctrl+Alt+F1 the system will open up eg. /dev/tty1 to my knowledge hijacking a /dev/tty session is very hard and requires kernel hacking. I have seen where a attacker can read from /dev/tty but never actually send commands to /dev/tty I believe it would be possible but I have not seen any proof of concept yet. If you opened up terminal in the start menu over X and ran su - you would be running bash under normal user and su would be piping root console directly to normal users terminal.
    – Tim Jonas
    Commented Jan 20, 2015 at 11:52

You must log in to answer this question.

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