Wandering Thoughts archives

The three faces of sudo

For reasons beyond the scope of this entry I've recently been thinking about my attitudes towards sudo. Sudo is a complex program with a lot of options and several different ways of using it, and in the process of my thinking I've realized that for me it's effectively three things in one (and I feel differently about each facet). So here are my three faces of sudo:

1. sudo as a replacement for having specific setuid programs. You're using it to give (passwordless) access to something for some group of people (or everyone); instead of writing a setuid program you use sudo to run a non-setuid program or script with the necessary privileges. Often you may want to wrap the sudo invocation up in a cover script so you can tell people 'just run /some/script'.

2. sudo as a way of giving non-sysadmin staff limited and guarded access to especially privileged and dangerous operations. This is the traditional 'operators are allowed to run reboot' situation, which I'll summarize as 'restricted root powers'. Here the people using sudo are not full sysadmins and are not trusted to hold unrestricted root privileges.

3. sudo as the way you access unrestricted root privileges, where use of sudo replaces su. You're encouraged to use sudo to run specific commands (even a bunch of commands) instead of using it to just get a root shell and then doing stuff from there.

   (In practice, use of sudo this way temporarily turns your current shell session into a peculiar privileged hybrid environment where you can use root powers casually by prefixing a command with sudo.)

I think that there are lots of uses for sudo as a replacement for setuid programs. Setuid programs are hard to write securely and can only be written in a few languages. Using sudo lets you more or less safely write 'setuid' programs in, say, shell scripts or Perl or the like. Invocation of them is a bit funny (you have to say 'sudo <program>') but that can be hidden by a cover script. We use this here for a number of things (eg) and it works great.

I'm less sanguine about sudo as a way to give out restricted root powers, especially if you let people run ordinary programs instead of only custom-designed scripts. Unless you're very careful it's easy to accidentally give people a way out of your restricted jail, since programs are generally not designed to enforce a restricted environment and contain all sorts of odd holes. For instance, if you allow people to run 'vi /some/file' as root you've just given them full root access if they want it. The whole area is a massive minefield if you're faced with an attacker.

(This doesn't require your operators to be malicious. Unfortunately you've turned compromising an operator account into a great path towards root access.)

My feelings about sudo as a replacement for su are sufficiently complicated that they don't fit in this entry. The short version is that I think you're likely to be creating a different security model with different risks; how different they are depends on how you configure sudo. The more you make the risks of sudo match the risks of su, the more you turn sudo into su.