8 Best practices with sudo on Linux – Do’s and Dont’s of sudo

All Linux users these days would be familiar with sudo command (stands for “superuser do”). We need to popularize sudo by enforcing rather than encouraging users to use su to gain root privileges for performing administrative tasks. But there’s much more you need to know about sudo. With the help of sudo you can easily execute commands as any another user, not just the root user! If sudo isn’t managed correctly, it’s almost worse than simply sharing root credentials, because it provides a false sense of security. Let’s look at some of the best practices for controlling system access with sudo while still allowing users to be productive. Know how to use sudo and follow these best practices, and then you can relax and enjoy every bite of your sandwich.

Note: You must use the visudo command to edit the /etc/sudoers file. Becareful while editing!

1. Do not allow unlimited access to users with sudo

Do not configure sudo to allow users to switch to root or any another account. Instead, try to configure sudo to allow users to run specific commands as the users they need to operate as.

For eg: There’s a need for an user to install a software. Allow them to run only RPM or APT or YUM as root without even switching to the root user as shown below:

peter ALL =(ALL) PASSWD : /usr/bin/apt-get, /usr/bin/yum, /bin/rpm

This would allow peter to run sudo apt-get, sudo yum and sudo rpm without any password but would not allow any other commands!

2. Do not grant ALL root privileges to a sudo user

Do not use ALL while granting access permissions to a sudo user. It is one of the most common mistakes admins would do. This allows users to use the su command to grant themselves permanent root privileges thereby bypassing the command logging features of sudo.

peter    ALL=(ALL:ALL) ALL

A better way is to grant access to specific program files for eg: User peter would gain access to all the program files in the /sbin/ and /usr/sbin directories, plus the command /opt/oracle/check.pl.

Note: Trailing slash(/) is required to specify a directory location

peter ALL=(ALL) PASSWD: /sbin/, /usr/sbin, /opt/oracle/check.pl

3. Do not grant unlimited passwordless access to root privileges

For instance, think an intruder gains access to an user account, who has passwordless sudo access to root privileges. He could do which you couldn’t even think of! Instead grant access to a user to root privileges with passwords(His own password).

peter    ALL=(ALL) PASSWD:ALL

This would allow user peter to input password every time he uses sudo to gain root privileges.

4. Use include directive for specific sudo configurations

Within large-enterprise environments, it is always better to keep a specific sudo configurations based on applications in addition to a local configurations. For eg: If you want to include the same set of directives for managing Apache and MySQL, you can break that into a seperate sudo.mysql file and use an include directive to call it from the main sudoers file.

#include /etc/sudo.mysql

5. Grant Sudo access to Groups rather than individual users

For eg: Have an admin group that has administrative privileges which manages installation and update to packages. This way, it’s not necessary to edit sudoers file each time you add/remove a new user. Simply ensure that users are appropriately managed and are added/removed from the admin group.

%admin ALL=(ALL) ALL

This will allow people in group admin to run all commands.

6. Set appropriate timeout for sudo

Sudo uses timestamp feature to know when was the last sudo command was run by the user. During this time period, the user can re-run the command without even being prompted for the password(user’s own password). By default sudo remembers your password for 15 minutes. Once it is expired, the user is prompted for the password again to re-run the command. If you wish to change the default value, simply put an entry in sudoers. For example, to set the timeout value for all users on any commands he runs to 5 minutes, you could use:

Defaults timestamp_timeout=x

where x is the timeout expiration in minutes. If you specify 0(zero) you will always be asked the password. If you specify a negative value, the timeout will never expire. E.g. Defaults timestamp_timeout=5

If you need to set for a particular user(peter) then simply put the below entry in sudoers file:

Defaults:peter timestamp_timeout=5

This feature will not work if you have NOPASSWD in the user’s entry in sudoers.

7. Lock the path for binaries using secure_path directive in sudo

A good practice is to lock down users to specific areas, thereby ensuring that users can’t execute commands outside the secure_path. Use the following directive in sudoers, specifying the secure_path:

Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

8. Log every sudo activity to a seperate file

By default, sudo commands logs to a logfile along with other system messages. This is not acceptible for servers as there would be a number of users. Configure sudo so that it has its own logfile for easy visibility into the use of sudo and activities of the sudoers. Of course, this also helps with keeping an eye on failed sudo events.

Defaults logfile=/var/log/sudo.log

If you have some more, please do add in the comments below.

Also Read : Secure your Web Server – 50 Best Practices To Follow