Sudos (and Sudon'ts)
by Chris Josephes
Related link: http://www.courtesan.com/sudo/sudo.html
A long time ago, I worked in an environment where everybody used sudo. Administrators, programmers, it didn't matter. There was no password prompting, and any command was available. The only advantage this setup offered was that it logged every command sent to it. Of course, the logging was worthless if someone types in
sudo bash, which was a common occurence.
I think sudo is a great tool, but there needs to be some thought behind its implementation. Here's a couple of suggestions I've learned from using sudo in the past.
Define who needs to use sudo
It's my feeling that regular systems administrators should not have to use sudo. If they're an administrator, and they are authorized to use the host in question, they should be trusted with the root password, a One Time Password phrase, or whatever authentication mechanism is used to grant root access.
Sudo's best feature is the ability to grant restricted root access. It's better suited for system operators that have clearly defined tasks, such as mail administration, or printer administration.
Create a restricted command path
Define what commands are going to be used with sudo, and who is going to use them. Put those commands in a restricted directory. If you have administrative roles that don't overlap, such as tape administrators or dns administrators, create seperate directories, or specify each command individually in the sudoers file. Make sure sudo users cannot write new files to these directories.
Create hardened scripts
It's very difficult to make a shell script 100% secure, especially if the script requires command line arguments. A script like the following can do some very bad things if it's involked improperly.
$ cat remove_home_dir
rm -rf /home/$1
Make sure the script is tested against tainted command line arguments, no arguments whatsoever, and tempfile race conditions. If necessary, create a C or Perl wrapper around the script, and use the wrapper to parse the arguments.
Prevent overuse of sudo with OTP
If you only give your users a limited number of One Time Passwords, you can gauge how often they're using sudo, and you might reinforce better behavior knowing they have a limited amount of opportunities to use certain commands.
Don't assume sudo prevents mistakes
A friend of mine told me about an intern who ran the following...
$ sudo "mv /etc/passwd /etc/passwd.tmp"
Now, if this person ran this command as root, he could have easily corrected his mistake before it became a problem. But because sudo dropped root privlidges when it exited, he totally hosed the server. This goes back to restricting what commands should be used with sudo.
Don't trust the environment or the user
I'm not suggesting deliberate misuse, but it's very easy to create the impression that sudo can prevent the user from doing any harm. That won't be too effective if it turns out sudo is blindly taking the user's PATH variable which may inadvertently reference bad applications.
env_reset option in the sudoers file strips many environmental variables from being passed to the sudo environment. It's a good step to making sure that your command scripts are more secure.
Don't overlook shell escapes
vi provide a handy shell escape sequence that lets you run commands within the program. You can see where I'm leading with this, right? Sudo provides a mechanism to restrict EXEC calls, but you should check to see if it is supported in your OS.
Don't overlook privilege escalation
Some operating systems have a privlege model providing an additional layer of security. Intead of creating security around certain commands, the OS provides prilidges for certain administrative roles, such as user X can administer the print queue, or user Y can reboot the host.
If your OS vendor gives you additional means of granting access with less effort than configuring sudo for the task, consider using it.
Never forget the first line of defense
You can harden your root environment or your /etc/sudoers file all you want. But it won't be very effective if your operator is accessing a server over the telnet protocol through an unsecured wireless Internet cafe on a laptop (that clearly identifies his employer), which he leaves unattended when he goes off to the bathroom.
Take the steps to make sure your host and user security is in place, then worry about your sudo configuration.
Come on. You know I had to do it.