Best Practices with sudo on Linux
Dos and Dont's of sudo
Best Practices with sudoMany Linux users are familiar with sudo these days. Ubuntu has done a lot to popularize sudo by enforcing its use in place of encouraging users to use su to switch to the root account to install software and perform other administrative tasks. But there's much more to sudo that users and admins should know.
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.
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 DownYes, sudo is a powerful tool, but it's also complex to configure well and difficult to maintain. When used with a minimal number of systems by experienced admins, it's an adequate method of implementing role based access controls. But for larger shops with dozens of IT staff and tens or hundreds of servers, sudo quickly starts to show its flaws. You can shore up sudo with additional tools. One way is to use a configuration framework like Puppet to manage sudo configurations across multiple systems. This can be particularly effective in shops that are primarily Linux and Unix based, though Puppet's learning curve may be a bit steep.
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
Solid state disks (SSDs) made a splash in consumer technology, and now the technology has its eyes on the enterprise storage market. Download this eBook to see what SSDs can do for your infrastructure and review the pros and cons of this potentially game-changing storage technology.
- 1Linux Top 3: RHEL 6.7, BackBox Linux 4.3 and RoboLinux 8.1
- 2Linux Top 3: SLES 11 SP4, Chromixium OS 1.5 and Canonical Licensing
- 3Linux Top 3: VirtualBox 5, Point Linux 3.0 and OpenSUSE Leap 42.x
- 4Linux Top 3: Linux 4.2 rc1, 4MLinux 13 and antiX15
- 5Linux Top 3: Linux Mint Rafaela, OpenMandriva Lx 2014.2 and VectorLinux 7.1