== 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_: # _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_'. # _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. # _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 ') but that can be hidden by a cover script. We use this [[here http://cs.toronto.edu/]] for a number of things ([[eg ../sysadmin/SystemEvolution]]) 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_.