The security model of sudo versus su

May 13, 2014

Some time ago I wrote about the three faces of sudo, where one of the faces was basically 'sudo as the replacement for su in how sysadmins get unrestricted root privileges' and I said that this created a different security model than with su. Today I want to talk about what that new model is and how I see it differing from su's in a way that makes me like it less.

To start with we need to talk about the security model of su. Su has a simple security model: you must know the root password and generally be in a restricted group. Then you can either get a root shell or execute a command as root by giving su the root password, and you must do this for every shell or command that you want.

(If your version of su is not configured to require membership in group 'wheel' or the local equivalent, the security model is that anyone at all who knows the root password can use su to assume root powers.)

Sudo's normal security model is that if you are in a restricted group and know your own password, you can run commands as root or get a root shell by typing your own password. Once you've typed your password once you can then run commands as root without any prompt for a certain amount of time.

There are two big differences between these two security models. The first is the choice of password that you are challenged with, where sudo's choice is noticeably weaker. With sudo the security of root access rests not on the root password alone but the passwords of everyone who has root access. Since people's regular passwords are used much more often and more broadly than the root password, my view is that they are more exposed (including stored in programs). An attacker who compromises even one sysadmin password now has immediate access to root by logging in as the sysadmin and repeating the password that they already know; they don't need to compromise an additional secret.

The second is that sudo effectively creates a temporary environment where you have root powers by using a magic prefix. An attacker that can detect this environment (or try blindly) and inject commands into it (either directly or, for example, via a shell script that you're running) can hijack this special power even without knowing your password and immediately use root powers. My view is that this makes a post-sudo shell session unusually dangerous and damaging. It also somewhat increases the possibility of simple accidents, since an errant sudo command will go through without a pause that would give you a chance to reconsider.

Either or both of these changes can be turned off via sudoers settings. But then you've reduced sudo to a variant of su. Maybe that's what you want (sudo does have better logging than su and some additional features), but I don't think it's the common way to use sudo as a su replacement. Maybe I'm wrong here, though; I'd be interested to hear if places that use sudo as a su replacement turn off these.

Comments on this page:

On the tradeoffs involved in the sudo no-password period:

My experience (of my own practice and what I've seen of others') is that with su, people are much more likely to open a root shell, rather than using su to run individual commands as root. The reason is obvious: If it turns out you need to run a series of commands as root (and it often does, even if you didn't know it when you entered the first one), it's cumbersome to have to type the root password for each one.

But with sudo, it's easy enough to prefix each command in a series with "sudo ", so there is much less reason to open a root shell.

The consequent danger with su is that people leave terminal windows lying around with root shells open on various machines. The sudo no-password period is better in that it ends automatically, and its status is not obvious from the shell prompt.

The weblog post mostly deals with the situation where you have only one group of people, and they become <root> (and only <root>) via either su or sudo.

There is also the situation where there are multiple groups (DBAs, Web Team, Storage, etc.) in an organization, and you want to give elevated access to some things, but not give out the <root> password. In smaller shops where everyone does everything (like in the author's case?), and has the password anyway, it's not a big difference between the two utilities. But if there's a Web Team, you can allow them to sudoedit the Apache configuration and restart via /etc/init.d/apache without giving them the keys to the proverbial kingdom.

This could also work with grad students and researches where a system/VM/instance has been provided to them to work on something, but they'll blow their leg off if given too much power. With power (ideally) comes responsibility, and many folks don't want that full responsibility and are quite happy to have limited access. (And then there are the folks who want full power, but no responsibility—sigh.)

There is also the case of "service accounts": if there is a <myapp> user (or <tomcat>, <postgres>, etc.) that an application runs under, we've found it advantageous to use sudo instead of su for them. The password for the service account is blocked in the shadow(5) (or LDAP) and so logins are not possible via SSH or su, but we allow certain folks/groups (and even ourselves) to become that service account for the work involved. This forces folks to SSH in as themselves and then become the service account—which helps with auditing. It's certainly possible to block logins via DenyUser in sshd-config(5), but it'd be a hassle to manage that for many machines. Similarly many service accounts are created during package installation with /bin/nologin as the shell and you may not want to change that, so a sudo -s can work.

As "David" also mentioned: with su people tend to run it once and have the shell that way—perhaps even jumping from system to system, so you get last entries that have <root> coming in from a remote IP: who exactly came in? The caching with sudo is good in that it allows one to stay as the "safe" regular account for most things, and only become elevated when needed.

The other things about sudo is that its configuration can be put into LDAP, and so if you want to make an access change you only have to hit one place to update things (the sudoHost attribute in a particular DN). If you use su with service accounts, you may possibly have to keep passed(5) and shadow(5) accounts synced.

There's also password changes (especially for service accounts). If someone leaves (either the organization or even just the group), if su is used everywhere then the password has to be changed everywhere; if sudo is used then their account can simply be locked (or removed from the sudoUser attribute). At one place I worked everyone used su to get to <root> and so the password was ingrained in muscle memory, therefore changes of staff were semi-painful because the shadow(5) file had to be updated everywhere (but this was scripted, so it wasn't that bad). In another place I worked at sudo was used, so while we still changed the <root> password, it wasn't as annoying because you just kept using your own password.

For the the last point: at that second organization I actually kept having to look up the <root> password from our password vault in certain cases (single-user boot) since I could never remember it because I used it so infrequently.

By cks at 2014-05-14 23:11:39:

@David Magda: I talked about what I saw as the other uses of sudo in the earlier entry, SudoThreeFaces. In this entry I wanted to focus purely on the 'sudo as the sysadmin replacement for su' face of sudo. I agree that sudo has significant uses for other cases and a better security model for them than alternatives like ahdn written setuid cover programs.

Use of su versus direct logins as root is partly a policy issue and partly a convenience issue, as is keeping root shells sitting around. I generally don't keep root shells sitting around even though I use su instead of sudo (and I generally wind up running a series of commands in a root shell when I start one up).

As for password propagation across multiple machines: this ought to be a solved problem in any well-run environment. I accept that it's not necessarily the case and that implementing LDAP for /etc/sudoers may be easier than implementing something for password propagation, but I can't help but think that the overall environment has some problems that are just being worked around.

Written on 13 May 2014.
« The advantages of editors over database programs for modifying your data
Modern mail forwarding is leaky »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue May 13 00:05:51 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.