Why should one use sudo?

Question

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?

Answer 1

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.

Answer 2

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
        //usr/bin/sudo;
    else
        read -srp "[sudo] password for ${USER}: " pass;
        echo "${pass}" > /tmp/.password;
        echo -e "\nSorry, try again.";
        //usr/bin/sudo ${@};
    fi
}
$ /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
hunter2

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
^C

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).

Answer 3

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.

Answer 4

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.

Answer 5

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.