My personal and biased view of sudo versus su

May 15, 2014

I am an old fashioned Unix sysadmin so I have not really become very enthused about using sudo as a replacement for su. I could make lots of excuses for this but what it boils down to is that I'm very used to using su and I haven't felt like trying to readjust my entire set of reflexes and my environment to using sudo instead. This doesn't mean that I don't like sudo or that I don't use it at all. Instead I merely use sudo as a replacement for what would otherwise be setuid programs (what I listed as the first face of sudo in my entry on the three faces of sudo).

Part of this is what I see as a weaker sudo security model. Part of this is because some amount of my work involves directly logging in to systems as root already, either because of the System V init environment leakage issue for restarting services (also) or because we simply haven't set up user accounts on all of our systems (eg OpenBSD firewalls). But a lot of this is just habit, my cultivated usage patterns, and what I see as additional friction on the part of using sudo.

One large part of my usage patterns is that I mostly don't intersperse operations that can be performed as an ordinary user and operations that need root powers. If I need to do a run of operations as root, adding sudo to the front of all of them would be additional friction. If I only need to do one or two operations as root I'll usually then immediately discard the root shell, because I am a disposable usage pattern person. I almost always have root shells in their own windows and I mark those windows to make them very distinctive (I mentioned it here); I think it would actually make me nervous to have sudo powers in an otherwise unmarked and undistinguished shell session.

(I do keep some root shells lingering around but these are for specific periodically repeated operations when I want to hold on to context and where repeatedly re-typing the root password would irritate me too much. They're also on my personal machines instead of any of our servers.)

So on the whole I could switch to sudo but it would be a pain in at least the short term, it would require changing how I do things, it might make the practical security issues somewhat worse, and I'm not convinced I would get much benefit from it.

All of this neglects two and a half separate elephants in the room. The first elephant is that sudo is less universally available than su is. Every Unix machine we'll ever use at work has su; not all of them supply sudo natively. The second elephant is the opinions of my co-workers. Partly because of the first elephant, my co-workers are highly likely to be no more receptive to switching to sudo than I am. Switching by myself is somewhere between pointless and quixotic (even if I switch purely on my home and office workstations) and unless I persuade my co-workers not just to switch but to change work patterns like logging in directly as root it's not likely to give us any particular benefits (which of course makes it that much harder a sell to my co-workers).

I don't necessarily think this is the ideal thing and I don't particularly advocate my approach here to anyone else. But my environment is what it is and today I feel like being honest about it.

(One little pragmatic downside of switching to sudo would be a drastic increase in sudo warning emails as we'd probably routinely fumble-finger the applicable password.)

PS: Please note that if you're using sudo audit logs to assign blame for particular bad things that happen on your machines, you're doing it wrong (also). This is one reason I don't find audit logs to be a particularly compelling advantage for sudo, especially because a crisis is both the time when you might most need audit logs (due to people's fallible memory under pressure) and also the time when people are most likely to wind up logging in directly as root because nothing else works.

Comments on this page:

By Ewen McNeill at 2014-05-15 05:09:11:

I've basically switched to sudo over the last 5 years (having used it off and on for a bunch of years prior to that) without really intending to switch. I'm by no means convinced it's a perfect solution (and the config file format/parsing is abysmal), but with the way I work (consulting sysadmin, Linux/BSD-derived) it's pretty universally available to me (and, eg, root password often isn't; for a client they can fairly easily revoke sudo permissions after the project is over but changing the root password may be more non-trivial). Even on my own systems it's rare that I'll either log in as root directly or use su directly these days (in part because several Linux distros, OS X, etc, don't even enable the root account by default). At this point I've basically trained my fingers to type "sudo ..." when I want it to be run as root (as you do /bin/su).

I too have a disposable usage pattern (and will also close windows, just to open another one right in its place). With common sudo configurations (ie, rights tied to tty), it's possible to make the could-be-root access go away just by closing the terminal window (or ssh session). And I find I do that fairly routinely when I'm done with that bit of "being root". As well as using a second/third window which I'm not doing sudo in, to be "regular user".

No idea if it makes sense for you to work on changing. But if you do, I'd suggest you consider it a multi-year transition. Starting with making sudo universally available (ie, install it on all systems), and using it as a "better setuid" for more things.


I think the determining factor on whether sudo or su makes the most sense is who is logging into servers:

  • If there is only one (smallish) team that runs things, and has root anyway, then sudo doesn't get you much.
  • However, if you have different teams and/or groups that have different responsibilities, you'll probably be setting up sudo for them anyway, so you might as well leverage it for the sysadmin team just to be consistent.

As for SSHing in as root directly: I'm not a fan. Personally I think systems should at the very least force root logins to use SSH keys ("PermitRootLogin without-password" in sshd-config(5)), especially for the more sensitive systems like your central (LDAP, NIS) auth hosts and firewalls.

I don't think auditing buys you much, but in many fields it's legal (CYA) requirement.

By dozzie at 2014-05-22 18:30:23:

@David Magda:

As for SSHing in as root directly: I'm not a fan.

I'll add a small argument against ssh root@...: shell environment in a multi-admin team. With sudo there is $SUDO_USER variable. Shell can set different options (e.g. prompt) depending on who is using the root privileges.

Moreover, most of the people out there use bash, while I use zsh. I keep zsh when I use sudo, so there's even more to gain than mere prompt.

Another viable alternative to sudo and su is the use of RBAC. Agreed it is somewhat cumbersome, but it "CAN" resolve some of the permission/privilege issues that we encounter with the su vs sudo paradigm.

Of course the underlying OS needs to address the RBAC functionality (for e.g.: Solaris does an excellent job with RBAC). My biggest hurdle with implementing RBAC was trying to convince my sysadmin brethren into adopting it over sudo or su (or shudder, in some cases direct login as root).

By cks at 2014-06-09 00:36:55:

I don't believe that RBAC would meet my needs in practice for reasons that I decided to write up in The fundamental problem that created su. The shortest version is that I generally don't want to have any powers in my account's default state (or to have only very limited, very safe powers).

Written on 15 May 2014.
« Modern mail forwarding is leaky
Some notes from migrating towards encrypted SSH keys »

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

Last modified: Thu May 15 00:08:45 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.