Best Practices with sudo on Linux

Dos and Dont's of sudo

Best Practices with sudo

What many users aren't aware of is that sudo can be used to execute commands as any user, not just the root user. In the hands of a skilled admin, sudo can be used to set up fine-grained permissions to provide users with access to perform a few administrative tasks without giving away the keys to the kingdom. Let's look at some of the best practices for controlling system access with sudo while still allowing users to be productive.

Remember, you must use the visudo command to edit the /etc/sudoers file.

It's tempting, and simpler, to give trusted users full access with sudo and allow them to execute any command as any user. Fight that temptation, because you want to limit access to the bare minimum whenever possible.

• Restrict account switching: If at all possible, do not configure sudo to allow users to switch to another account. Instead, try to configure sudo to allow users to run specific commands as the users they need to operate as. For instance, there's a need for the user to install software, allow them to run RPM or APT as root without switching to the root user.
• Don't use ALL: One of the most common mistakes is to grant ALL -- access to all commands, access to all users, or any other permutation. It can be time-consuming to lock down the access, but it's well worth the trouble.
• Split sudoers: If you have many systems to manage and don't want to copy the same /etc/sudoers file to all systems, you can break down the sudoers file into chunks and call include files with specific sudo configurations. So, for example, if you want to include the same set of directives for managing Apache and MySQL, you can break that into a separate sudo.mysql file and use an include directive to call it from the main sudoers file.
• Make use of groups: If possible, delegate authority by groups rather than individual users. For instance, have an admin group that has administrative privileges for managing packages and updates. This way, it's not necessary to edit sudoers each time you add or remove a new user -- simply ensure that users are appropriately managed and added/removed from the admin group.
• Timeout: Make sure that you have an appropriate timeout set. Too short, and users are going to be frustrated rather quickly. A good rule of thumb is about five minutes.
• Follow the right path: Lock down the path for binaries by specifying a secure_path directive in sudo -- ensuring that users can't execute commands outside the secure_path.
• Log to a separate file: By default, sudo may log to a common messages logfile along with other system messages. This is an acceptable setup for single user systems like an Ubuntu desktop, but not so terrific for servers. Configure sudo so that it has its own logfile for easy visibility into the use of sudo and activities of the sudoers.

Where sudo Falls Down

If your organization has deployed Microsoft Active Directory in a mixed network of Linux and Windows servers, you can use Likewise Enterprise to bridge Linux and Unix systems to Active Directory. Not only is it possible to tie Linux and Unix logins to Active Directory credentials, but also to manage sudo configurations for all servers in the network.

You can find other tools that help supplement sudo to provide more robust privileged user management. The important thing is to assess your network and decide whether sudo alone is sufficient to handle your needs. For small businesses, sudo is usually just fine -- if you follow best practices and stay on top of the sudo configuration. If sudo isn't managed correctly, it's almost worse than simply sharing root credentials, because it provides a false sense of security. Know how to use sudo and follow these best practices, and then you can relax and enjoy every sandwich.

Contributed by Yvo Van Doorn of Likewise Software