Now that we’ve looked at the basics of setting up a good sudo configuration in this article, we’re confronted with a bit of a paradox. That is, even though sudo is a security tool, certain things that you can do with it can make your system even more insecure than it was. Let’s see how to avoid that.

The sudo timer

By default, the sudo timer is set for five minutes. This means that once a user performs one sudo command and enters a password, he or she can perform another sudo command within five minutes without having to enter the password again. Although this is obviously handy, it can also be problematic if users were to walk away from their desks with a command terminal still open.

If you need to leave your desk for a moment, your best action would be to log out of the server first. Short of that, you could just reset the sudo timer by running this command:

#sudo -k

This is one of the few sudo actions you can do without entering a password. But the next time you do a sudo command, you will have to enter your password, even if it has been less than five minutes since you entered your password previously.

You can easily disable this timer by adding a line to the Defaults section of the sudoers file. This way, users will have to enter their passwords every time they run a sudo command.

  1. Open visudo with the following command:
#sudo visudo

2. In the Defaults specification section of the file, add the following line:

Defaults timestamp_timeout = 0

3. Save the file and exit visudo.

You should see that now you have to enter a password every time.

Limiting the user’s actions with commands

Let’s say that you create a sudo rule so that john can use the systemctl command:

john ALL=(ALL) /usr/bin/systemctl

This allows john to have full use of the systemctl features. He can control daemons, edit service files, shut down or reboot, and carry out every other function that systemctl does. That’s probably not what you want. It would be better to specify what systemctl functions that john is allowed to do. Let’s say that you want him to be able to control just the Secure Shell service. You can make the line look like this:

john ALL=(ALL) /usr/bin/systemctl * sshd

john can now do everything he needs to do with the Secure Shell service, but he can’t shut down or reboot the system, edit other service files, or change systemd targets. But what if you want john to do only certain specific actions with the Secure Shell service? Then you’ll have to omit the wildcard and specify all of the actions that you want john to do:

john ALL=(ALL) /usr/bin/systemctl status sshd, /usr/bin/systemctl restart sshd

Now, john can only restart the Secure Shell service or check its status.

Letting users run as other users

In the following line, (ALL) means that john can run the systemctl commands as any user:

john ALL=(ALL) /usr/bin/systemctl status sshd, /usr/bin/systemctl restart sshd

This effectively gives john root privileges for these commands because the root user is definitely any user. You could, if desired, change that (ALL) to (root) in order to specify that john can only run these commands as the root user:

john ALL=(root) /usr/bin/systemctl status sshd, /usr/bin/systemctl restart sshd

Okay, there’s probably not much point in that because nothing changes. john had root privileges for these systemctl commands before, and he still has them now. But there are more practical uses for this feature. Let’s say that harry is a database admin, and you want him to run as the database user:

harry ALL=(database) /usr/local/sbin/

harry could then run the command as the database user by entering the following command:

sudo -u database

View your sudo privileges

Are you unsure of what sudo privileges that you possess? Not to worry, you have a way to find out. Just run this command:

#sudo -l

When I do this for user rd, I first see some of the environmental variables for my account, and then I see that I have full sudo privileges

When john, does this for his account, he sees that he can only do the sshd command:

The following two tabs change content below.
Ruwantha Nissanka is a Professional Cyber Security Engineer from Sri lanka with having a demonstrated history of providing cyber security services for multiple organizations in Sri Lanka. He is a positive person who wants to believe the best in others and he likes to help, encourage people and make them feel good.