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
:
sudoas 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 usesudoto run a non-setuid program or script with the necessary privileges. Often you may want to wrap thesudoinvocation up in a cover script so you can tell people 'just run/some/script'.sudoas 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 runreboot' situation, which I'll summarize as 'restricted root powers'. Here the people usingsudoare not full sysadmins and are not trusted to hold unrestricted root privileges.sudoas the way you access unrestricted root privileges, where use ofsudoreplacessu. You're encouraged to usesudoto 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
sudothis way temporarily turns your current shell session into a peculiar privileged hybrid environment where you can use root powers casually by prefixing a command withsudo.)
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
.