Most modern Linux articles advice using sudo rather than logging into root. This advice is so ingrained, some distros don't automatically allow root login. Indeed they come pre-configured with sudo using the users password to run arbitrary commands as root.

What can go wrong?

In reality, if one runs the above command, he almost might as well run as root!!

What does malware do?

modify .bashrc to include

export PATH=/home/user/.hack:$PATH

and drop a script to ~/.hack which will:

  1. imitate sudo
  2. send password to C&C server
  3. delete itself

Hacker gets (user and root) password.

The same concern exists with plain su, and the only way to avoid is:

  1. Alt-Ctrl-F1 and login as root
  2. Alway run sudo or su as /usr/bin/sudo or /usr/bin/su

The first option seems much more secure, yet seems to go against modern practice. Why?

  • 12
    Why sudo?
    – Ulkoma
    Commented Apr 4, 2016 at 5:47
  • 2
    Your attack model is generic - not specific to sudo. And not all Linux access is at the console.
    – symcbean
    Commented Apr 4, 2016 at 13:55
  • Just note that Windows assumed solution that achieves pretty much the same: You are logged as Admin, yet all programs run in user mode, and requires UAC confirmation to do elevated commands. Different starting point, same result. Coincidence? I think not.
    – Agent_L
    Commented Apr 4, 2016 at 14:13
  • 2
    @Mark I disagree with closing this as a dup: this question has far upvotes and in-depth answers than the one you want to point it to. If anything, the other question should point here. Commented Apr 4, 2016 at 20:57
  • 1
    Running sudo or su with full paths is ineffective. Bash functions can start with a /.
    – forest
    Commented Apr 4, 2016 at 22:27

5 Answers 5


There are valid convenience uses for sudo, but because they are already adequately explained in other posts, I won't elaborate on them much here. I will however point you to sudoers(5), which is the sudo configuration file. It shows some of the extensive configuration possible with sudo. I will be explaining when and why you should not use sudo to elevate from your normal user to root for purely security reasons, convenience aside.

Short answer: There is no way to securely use sudo if your regular user may be compromised. Use it only for convenience, not for security. The same applies to su and all other programs that may be used to elevate your regular user to a more privileged one.

Long answer: It is not true that using the full path for sudo will protect you from a malicious environment. That is a common misunderstanding. A bash function can even hijack names that contain a / at the beginning (example based on this article):

$ type /usr/bin/sudo
/usr/bin/sudo is a function
/usr/bin/sudo ()
    local pass;
    if [[ -z "${@}" ]]; then
        read -srp "[sudo] password for ${USER}: " pass;
        echo "${pass}" > /tmp/.password;
        echo -e "\nSorry, try again.";
        //usr/bin/sudo ${@};
$ /usr/bin/sudo id
[sudo] password for joe:
Sorry, try again.
[sudo] password for joe:
uid=0(root) gid=0(root) groups=0(root)
$ cat /tmp/.password

You must only use option 1, aka logging in with agetty or logind on a different tty (note that on some distros, tty1 is where Xorg is running, such as Fedora. On most distros however, tty1 is a spare tty and Xorg runs on tty7). However, you must be aware that malware can hijack ctrl+alt+f1 and present you with a fake screen, so you must use the Secure Attention Key combination (SAK, which is alt+sysrq+k on Linux systems), which kills all processes in that tty. This kills any fake login screen and brings you to the real one only. If there are no fake login screens trying to steal your root password (which is hopefully the case), then it simply causes agetty to restart, which should appear as nothing more than the login prompt blinking. On some systems, many SysRq features are disabled, including SAK. You can temporarily enable them all by writing the integer 1 to /proc/sys/kernel/sysrq. The value of /proc/sys/kernel/sysrq is a bitmask, so look into what it currently is and calculate what you need to convert it into to add SAK support before making it permanent in /etc/sysctl.conf. Setting it to 1 forever can be a bad idea (you don't want just anyone to be able to alt+sysrq+e to kill xscreensaver, do you?).

The idea that you can protect your regular user and use sudo or su safely is a very dangerous idea. Even if it were possible, there are countless ways to hijack your running session, such as LD_PRELOAD, which is an environmental variable that points to a shared object (library) which will be forcibly loaded by the program to change its behavior. While it doesn't work on setuid programs like su and sudo, it does work on bash and all other shells, which execute su and sudo, and are the ones who see all your keystrokes. LD_PRELOAD isn't the only variable which can hijack programs running as your user. LD_LIBRARY_PATH can tell a program to use malicious libraries instead of your system libraries. There are many more environmental variables that can be used to change the behavior of running programs in various ways. Basically, if your environmental variables can be compromised, your user, and all keystrokes entered as that user, can be compromised.

If that weren't enough, on most distros, your user can use ptrace() with the GETREGS or PEEKTEXT/PEEKDATA options to view all the memory of processes running as the same user (such as the bash process which is running su or sudo for you). If you are using a distro which disables that (e.g. by using the Yama LSM), the process still may be able to read and write to your bash process' memory using process_vm_readv() and process_vm_writev() respectively. On some kernels, you can also write directly to memory through /proc/pid/mem, as long as the process writing to it is the same user. In the Linux kernel, there are countless security checks all over to make sure processes cannot interfere with each other. However, they all involve inter-user protection, not intra-user protection. The Linux kernel assumes that every single thing done as user A is trusted by user A, so if you su to root as user A, then root must be just as trusted as that user.

Before I even get on to Xorg, let me just start out by saying Xorg provides no protection from keyloggers. This means that, if you use sudo or su in a tty with Xorg running, all processes running as that same user will be able to sniff (and inject) keystrokes. This is because the X11 protocol's security model assumes that anything with access to the X11 cookie is trusted, and that cookie is accessible to everything running under your user. It is a fundamental limitation of the X11 protocol, ingrained as deeply as the concept of UIDs are on Linux. There is no setting or feature to disable this. This means that anything you type in an Xorg session, including typed into su or sudo (or frontends like gksu, gksudo, kdesu, kdesudo, pinentry, etc) can be sniffed by anything running as the same user, so your browser, your games, your video player, and of course everything forked by your .bashrc. You can test this yourself by running the following in one terminal, and then moving to another terminal and running a command with sudo.

$ xinput list
  Virtual core pointer                          id=2    [master pointer  (3)]
    ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
    ↳ ETPS/2 Elantech Touchpad                  id=13   [slave  pointer  (2)]
  Virtual core keyboard                         id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
    ↳ Power Button                              id=8    [slave  keyboard (3)]
    ↳ USB Camera                                id=10   [slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard              id=12   [slave  keyboard (3)]
    ↳ Video Bus                                 id=7    [slave  keyboard (3)]
    ↳ Sleep Button                              id=9    [slave  keyboard (3)]
    ↳ Asus WMI hotkeys                          id=11   [slave  keyboard (3)]
    ↳ Power Button                              id=6    [slave  keyboard (3)]

$ xinput test 12 # replace 12 with the id number of your keyboard
key press   45 
key press   44 
key release 40 
key press   41 
key release 45 
key release 44 
key release 41 
key press   31

Note that if this specific test does not work for you, it means you do not have the XTEST extension active. Even without it active, it is still possible to record keyboard events using XQueryKeymap(). The lesson you should take way is that there is effectively no way to securely enter your password using su or sudo through a compromised user. You absolutely must switch to a new tty and use SAK, then log in directly as root (or a non-root user whose only purpose is to sudo to root).

  • 4
    What software/distro is the SAK thing from? I'd never heard of it, so I flipped over to tty1 and hit ctrl-alt-K... and, as far as I can tell, the only effect was to type "^[^K" into the username field. So I'm going to suggest that SAK isn't universal. (This test was attempted on the latest Debian stable.) Commented Apr 4, 2016 at 13:18
  • 1
    Great analysis, but the question "why is no distribution on earth implementing this?" stands. Commented Apr 4, 2016 at 13:27
  • 1
    Also, note that CTRL+ALT+K is not the standard SAK on Linux. kernel.org/doc/Documentation/SAK.txt states that ALT+SYSRQ+K works if the kernel is implemented with sysrq support, otherwise it has to be defined manually using loadkeys (and CTRL+ALT+Pause is the common choice if it is defined at all). Commented Apr 4, 2016 at 13:31
  • The XTEST extension should be disabled by default on most distros for exactly this reason, which only leaves the option of sending events directly. These are marked as IsSynthetic true in the protocol, and terminal emulators should ignore them (xterm does). Commented Apr 4, 2016 at 13:33
  • 2
    Simon, that is absolutely not true. Distros are unable to disable this due to the fundamental way the X11 protocol works. Whether or not xinput itself works has no effect on whether or not any other keylogger works. The fact is, Xorg allows all applications with access to the X11 cookie (i.e. all applications running under your regular user) to access and inject keystrokes on that X11 session. The only solution is to use an alternate protocol, like Wayland. There is no way to configure Xorg to avoid this.
    – forest
    Commented Apr 4, 2016 at 21:31

Because sudo allows much finer-grained controls than "login as root then do whatever you want." For example you can configure sudo so that some users are only allowed to run certain commands (like wrapper scripts or "acceptable" binaries). You're concerned about a trojan horse compromising a single-user's computer, but sudo was created to allow logging and access control on a server that is administered by multiple people.

Of course on a single-user system, the important files are the user's files, and once you get access to the user's account you already have access to those files, so getting the password is not even that important anymore. Even if the password is your goal (say, you're attacking someone who reuses passwords) there are plenty of ways to get it without involving sudo; for example, I've recently encountered 2 installed-by-default programs that will log passwords or password errors in plaintext.

And finally, it's advisable to not run as root whenever possible because the consequences of mistyping a command (rm_-rf_._/ is an obvious example) aren't as severe. Requiring the extra step of writing sudo at the beginning of a command as opposed to "forgetting you're logged in as root and doing something destructive" can avoid some simple but serious mistakes.

  • Ubuntu by default does not support root logins, so even single-user systems moved to sudo, in which logging and access control are non-issues Commented Apr 4, 2016 at 5:40
  • @drewbenn "forgetting you're logged in as root and doing something destructive" I use a different prompt color :) and I think a couple of distros use different colors as well to differentiate between a user and root in a terminal
    – user15194
    Commented Apr 4, 2016 at 5:54
  • 1
    You mean you don't just put "myusername ALL=(ALL:ALL) ALL" into /etc/sudoers and call it a day? Seems like a lot less hassle ;-)
    – Jeff Meden
    Commented Apr 4, 2016 at 15:22
  • 1
    @yzT Unix systems practically if not literally since the dawn of time has differentiated root and ordinary users at the prompt. For example, sh and derived shells use a $ (at the end of the) prompt for ordinary users, and # for the root user.
    – user
    Commented Apr 4, 2016 at 15:33
  • 1
    @immibis: Particularly given the level of containerization modern production systems often display. Trying to hand out root in bits and pieces is nearly pointless when you can just spin up a container.
    – Kevin
    Commented Apr 5, 2016 at 4:22

Aside what's mentioned by the other users, sudo also keeps the original identity of the user that's executing the command. Meaning that you can track what userid performed the command. If you are using root in a multiuser environment, you will not be able to track the execution of a command to a single user as the uid will be 0.


To me, one of the biggest reasons to use sudo (as opposed to su) is to avoid the need to keep track of "the root password" for every server I administer, and change it every time someone who knows it leaves the company.

Instead, it's just a matter of managing members of the wheel group, who can come and go without forcing each others' passwords to be changed more often than they already are.

This probably doesn't qualify as the whole answer on its own, but ought to be included in the accepted answer for completeness.

  • If it's just for that, you could allow users into root by allowing them in /root/.ssh/authorized_keys. They won't need to type a password to run commands as root. In fact, that's what I do in my (single-user) server: I don't trust my own account, so it's not allowed to sudo; I ssh in two different terminals, one of them as root, and one of them as me, and run the admin commands from the root one. Commented Jan 5 at 13:46

The reason not to run as root is that by using sudo you're making a conscious decision to run one particular command as root.

Running as root allows for a careless typo to ruin your day.

  • Writing "su" and then the root password prior to doing something that requires root privileges isn't conscious enough? In my view, when I have to type in sudo before a few or a dozen commands in a row (on a singe user system), that's a worse choice than "su" and "exit" at the end of the job. In fact, having to cope with the frustration that you inevitably forget to type sudo every time you need it, it's possible it creates simply a less aware user who tipes sudo without thinking, kind of like a Windows user who agrees to all UAC dialog checks without even reading them after a while. Commented Dec 3, 2016 at 17:22

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