Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
documentation.suse.com / Configuring Superuser Privileges with sudo

Configuring Superuser Privileges with sudo

Publication Date: 05 Dec 2024
WHAT?

Get familiar with the basics of sudo configuration and learn how to delegate superuser privileges with sudo.

WHY?

Some commands require administrator or root privileges. Using sudo, you can delegate the privileges to execute these commands to certain users or groups.

EFFORT

It takes you up to 20 minutes to read through this article. Writing your first sudo configuration rule only takes a few minutes, but establishing a functioning sudo configuration that works across your environment will take considerably longer, depending on the complexity of your setup.

GOAL

Understand the basic aspects of sudo configuration. Address common use cases for sudo configuration. Learn how to work with users, user groups and aliases in sudo setups. Familiarize yourself with sudo best practices and troubleshooting.

REQUIREMENTS

1 An introduction to sudo configuration

sudo provides a means to securely and efficiently delegate superuser privileges to specific users or groups.

Certain operations on a Linux system require root or administrator privileges. Home users who administer their own system do not have to delegate superuser privileges, because the administrator and the normal user are the same person in this scenario. But as soon as a system is part of a larger systems environment with multiple users, groups and hosts, it becomes vital to maintain control of who is allowed to do what and where. At the same time, it is important to provide all users and groups with the necessary privileges to carry out their tasks.

sudo is designed to help with this. It provides:

Enhanced system security

sudo offers fine-grained control over users, groups, hosts and commands and thus increases system security by reducing the risk of malicious or accidental damage by an intruder or a system user.

Complete audit trail

Whenever a user switches privileges, this appears in the system's log, and all operations carried out by this user with elevated privileges can be traced back to them.

A means to delegate root-specific tasks

Using sudo, system administrators can enable single users or groups to carry out certain tasks without the need to enter the root password and switch to the root account.

Important
Important: How to read this article

This article provides in-depth sudo configuration information. However, it does not provide any advice on how to build a comprehensive and secure sudo policy. Security-related policies are very complex and strongly depend on the environment they are created for.

2 Creating custom sudo configurations

Learn how to build a simple example custom sudo configuration and expand it step by step. Create groups and use aliases to keep your custom configuration lean and efficient.

Warning
Warning: Example configurations are for demonstration purposes only

The example rules outlined below are purely for demonstration purposes. Use them to understand the general syntax of sudo configuration files. Do not use them in real-world setups, because they do not reflect the complexity of these environments.

2.1 sudo configuration best practices

Before your start, here are a few ground rules for maintaining sudo configurations:

Always use visudo to edit sudo configuration files

Any changes to the sudo configuration should be done using the visudo command. visudo is a tailor-made tool that allows you to edit the sudo configuration files and runs basic syntax checks, making sure that the configuration remains intact and functional. A faulty sudo configuration can result in a user being locked out of their own system.

Always create custom configurations under /etc/sudoers.d/

Custom configurations must reside under /etc/sudoers.d/ to be pulled in by sudo. Settings in the custom configuration files take precedence over the ones in the default configuration in /etc/sudoers.

Always mind the order in which configurations are read

To make sure the custom configurations are read in the correct order, prefix them with numbers. Use leading zeroes to establish the order in which the files are read. For example, 01_myfirstconfig is parsed before 10_myotherconfig. If a directive has been set in a file that is read before another file that contains conflicting information, the last-read directive is applied.

Always use descriptive file names

Use file names that hint at what the configuration file does. This helps you keep track of what your sudo setup is supposed to do.

Tip
Tip: sudo configuration and immutable file systems

An immutable file system is a file system that cannot be changed once it has been installed. It is accessed read-only. If the SUSE product you are using relies on an immutable file system, the sudo default configuration shipped with the product is installed under /usr/etc/sudoers and any pre-configured adjustments reside under /usr/etc/sudoers.d/.

Your own custom configurations are located under /etc/sudoers.d/ and take precedence over anything that is provided in /usr/etc/sudoers.d/. The visudo command opens /usr/etc/sudoers and saves the changed file to /etc/sudoers, if there was no prior sudoers file. If there was already one, visudo opens and writes that one. The instance located under /etc/ takes precedence over the one that is kept under /usr/etc/. This way, user-made configuration adjustments will not get broken upon updates.

2.2 Create a user-specific configuration file

Create a sudo configuration file that allows a normal user (tux) to use the useradd command with their own password instead of the root password.

Example 1: Create a user-specific configuration file
  1. As system administrator (root), create a custom configuration file that holds the new user-specific directives by starting visudo. Use both numbering and a descriptive name:

    # visudo -f /etc/sudoers.d/02_usermanagement
  2. Create a rule that allows tux to execute the /usr/sbin/useradd binary in the entire environment that this sudo configuration is applied to:

    tux1 ALL2 = /usr/sbin/useradd3

    1

    Specify the user or group. List users by name or #UID, and groups by %GROUPNAME. If you have several items here, separate them with commas. To negate entries, use !.

    2

    Specify one or several (separated by commas) hosts. Use (fully qualified) host names or IP addresses. Add ALL to enforce this setting globally across all hosts. Use ! for negations.

    3

    Specify one or several executables (separated by commas). When specifying them, make sure to mind the following rules:

    /usr/sbin/useradd

    Without any additional options added, this allows the execution of every possible useradd command.

    /usr/sbin/useradd -c

    If you explicitly specify an option, then that option is the only one that is allowed. Nothing else would be available to the user you specified above.

    /usr/sbin/useradd ""

    This would just let the user invoke a mere useradd without any option at all.

    In the example above, you would want to either allow all options and subcommands or limit them to a few for security reasons, but forbidding a user to specify any option at all would be pointless in this context.

  3. To let the user use their own password instead of the root password, add the following line:

    Defaults:tux !targetpw

    When active, this flag requires the user to enter the password of the target user, i.e. root. This flag is enabled by default on any SUSE Linux Micro system. Negate it using ! to require the user to just enter their own password instead of the root password.

  4. Save the configuration, leave the editor and open a second shell to test whether sudo honors your new configuration.

2.3 Create custom configurations by grouping items

Modify the configuration from Example 1, “Create a user-specific configuration file” so that a group of named users can run the useradd command without the need for the root password. Also, add the usermod and userdel to the list of commands available to this group.

Example 2: Create custom configurations by grouping items
  1. To modify the example configuration, open it as system administrator with visudo:

    # visudo /etc/sudoers.d/02_usermanagement
  2. Add more users to the rule in a comma-separated list:

    tux, wilber ALL = /usr/sbin/useradd
  3. To allow the listed users to execute a list of commands, specify the commands as a comma-separated list:

    tux, wilber ALL = /usr/sbin/useradd, /usr/sbin/usermod, /usr/sbin/userdel
  4. To let the listed users use their own password instead of the root password, add the following line:

    Defaults:tux, wilber !targetpw

    When active, this flag requires the listed users to enter the password of the target user, i.e. root. This flag is enabled by default on any SUSE Linux Micro system. Negate it using ! to require the listed users to just enter their own password instead of the root password.

  5. Save the configuration, leave the editor and open a second shell to test whether sudo honors your new configuration.

2.4 Simplify configurations by applying aliases

Use aliases to simplify your custom configuration from Example 2, “Create custom configurations by grouping items” even further. Grouping items helps to a certain extent, but using global aliases for users, commands and hosts is the most efficient way to keep a clean and lean sudo configuration.

Using aliases and groups instead of lists is a much better way to address changes in your setup. Should a user leave, just remove them from the global User_Alias declaration in your alias declaration file instead of scouring all the separate custom configuration files. The same procedure applies for any other type of alias (Host_Alias, Cmnd_Alias and Runas_Alias).

Example 3: Simplify configurations by applying aliases
  1. Create a new file to hold your global alias definitions:

    # visudo /etc/sudoers.d/01_aliases
  2. Add the following line to create the TEAMLEADERS alias:

    User_Alias    TEAMLEADERS = tux, wilber
  3. Add the following line to create the USERMANAGEMENT alias:

    Cmnd_Alias    USERMANAGEMENT = /usr/sbin/useradd, /usr/sbin/usermod, /usr/sbin/userdel
  4. Save your changes and exit visudo.

  5. As system administrator, start visudo to edit the example configuration file:

    # visudo -f /etc/sudoers.d/02_usermanagement
  6. Delete the previous rule and replace it with the following rule that uses the aliases you have just defined above:

    TEAMLEADERS ALL = USERMANAGEMENT
  7. To let all the users defined by User_Alias use their own password instead of the root password, add the following line:

    Defaults:TEAMLEADERS !targetpw
  8. Save the configuration, leave the editor and open a second shell to test whether sudo honors your new configuration.

Note
Note: For more information

Find a more detailed description of the sudo configuration syntax in Section 7, “sudo configuration reference” and refer to the man page of sudo.

3 Changing the sudo password prompt timeout

Learn how to change the timeout settings to execute commands that require root privileges without being prompted for the root password for each command.

When running a command prefaced with sudo for the first time, you are prompted for the root password. This password remains valid for a certain period. Once it is expired, the user is prompted for the password again. To extend or shorten the timeout when executing commands that require root privileges, make the following changes to your sudo configuration file.

Warning
Warning: Do not grant unlimited passwordless access to root privileges

For security reasons, do not give unlimited access to root privileges. Instead, set a reasonable timeout to prevent misuse of the root account by any intruder.

Procedure 1: Changing the timeout for sudo password prompts
  1. As system administrator, create a new sudo configuration file for the timestamp configuration with:

    # visudo --f=/etc/sudoers.d/timestamp_timeout

    After successful authentication with the root password, the file is opened.

  2. Enable editing and add the line timestamp_timeout=. Enter a value for the timestamp.

    For example, to shorten the timeout to three minutes, enter:

    timestamp_timeout=3

    If the timestamp is set to zero, you are prompted for the root password for every execution of a sudo command.

  3. Save the changes and close the file.

You have created a sudo configuration file and shortened the timeout setting for the execution of sudo commands.

4 Starting a shell with root privileges

Start a shell with permanent root privileges by using the sudo -s or sudo -i command. With both commands, you are prompted for the root password only once.

4.1 Difference between sudo -s and sudo -i

Having to enter sudo every time you want to run a command as root can become tedious. Instead, you can use one of the built-in mechanisms to start a shell with permanent root privileges. For this, there are two command options available:

  • sudo -s launches the shell with the environment of the current user and offers a few privilege control measures. To run this command, enter the root password.

  • sudo -i starts the shell as an interactive login shell with a clean environment. To run this command, you enter the root password.

With both commands, the shell is started with a new environment, and you are logged in as root. Any subsequent command that is executed within that shell is run with elevated privileges without having to enter the password again. This environment is terminated when you close the shell, and you must enter the password again for another sudo command.

4.2 Starting a shell with sudo -s

The sudo -s command launches an interactive non-login shell. After successful authentication with the root password, all subsequent commands are executed with elevated privileges.

The SHELL environment variable or the user's default shell specifies which shell opens. If this variable is empty, the shell defined in the /etc/passwd is picked up.

By default, the sudo -s command runs from the directory of the previous user because the target user inherits the environment of the previous user. The command is also logged in your history.

To start a shell with permanently elevated privileges, enter the following command:

tux:~ > sudo -s
[sudo] password for root:
root:/home/tux # exit
tux:~ > 

The prompt changes from > to # .

You have started a shell with permanently elevated privileges. All subsequent commands are executed without prompting for the password again.

4.3 Starting a shell with sudo -i

The sudo -i is similar to the sudo -s command-line option but launches an interactive login shell. When using the sudo -s command, the target user inherits the environment of the previous user. You can prevent it by using the sudo -i command, where the target user gets a clean environment and starts at their own $HOME directory.

To run a command with sudo -i, enter the following:

tux:~ > sudo -i
[sudo] password for root:
root:~ # exit
tux:~ > 

You have started a shell with permanently elevated privileges, and the command is logged in your history. All subsequent commands are executed without prompting for the password again.

5 sudo best practices

Learn about some of the best practices of sudo to control system access and enable users to be productive.

Thoroughly test and audit your sudo configurations

To build a truly efficient and secure sudo configuration framework, establish a routine of regular testing and auditing. Identify possible loopholes and deal with them. Do not let convenience trump security.

Keep custom sudo configurations in separate files

The main policy configuration file for sudo is /etc/sudoers. This file is supplied by the system packages, and changes made to it may break updates. Therefore, create separate configuration files holding your custom settings under the/etc/sudoers.d/ directory. These are pulled in by default by a directive in /etc/sudoers.

Limit the sudo timeout

For security reasons, do not give unlimited access to root privileges. Instead, set a reasonable timeout instead to prevent misuse of the root account by any intruder. For more information, refer to Section 3, “Changing the sudo password prompt timeout”.

Use the visudo command

Use the visudo command to safely edit the /etc/sudoers file, because it checks the syntax of the file before saving the changes. This is a preventive way to correct any errors that can break the system. Besides the basic syntax check, you can also run visudo -c to check whether your entire framework of sudo configuration is parsed in the right order and without an error.

Manage users in groups rather than individually

Keep your sudo configuration as lean and manageable as possible. Manage users by adding them to groups and then granting privileges to these groups rather than to the individuals. This allows you to add or remove users by simply changing the group settings instead of having to look for the user across your configuration.

An example rule that allows all users in an example %admingrp group to execute all commands:

%admingrp ALL = (ALL) ALL
Restrict the path for binaries

With the secure_path directive, restrict the areas where users can execute commands. The following example is the default setting that ships with SUSE Linux Micro.

Defaults secure_path="/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/bin:/usr/local/sbin"
Keep sudo logging transparent

sudo logs to the standard log file where its log entries may easily get overlooked. Add the following rule to your configuration to specify a dedicated sudo log file.

Defaults logfile=/var/log/sudo.log

6 Troubleshooting

Learn how to debug and troubleshoot sudo configuration issues.

6.1 Custom configurations under /etc/sudoers.d/ are ignored

The #includedir directive in /etc/sudoers ignores files that end with the ~ character or contain the . character. This is to avoid issues with configuration files provided by the package manager (containing .), or with an editor's temporary or backup files (ending in ~). Make sure that the names of your custom configuration files neither contain nor end in these characters. If they do, rename them.

6.2 Custom directives conflict

The order in which the configuration files are read determines when a sudo configuration directive is applied. Directives in a file located under /etc/sudoers.d/ take precedence over the same directives in /etc/sudoers. If custom directives stated in /etc/sudoers.d/ do not work, check the order in which the files are read using visudo -c. Adjust the order, if necessary.

6.3 Locked out due to broken sudo configuration

If you have accidentally broken your system's sudo configuration and locked yourself out of sudo, use su - and the root password to start a root shell. Run visudo -c to check for errors and then fix them using visudo.

7 sudo configuration reference

This section provides a basic sudo configuration reference that helps you understand and maintain both default and custom sudo configurations.

7.1 sudoers configuration syntax

The sudoers configuration files contain two types of options: strings and flags. While strings can contain any value, flags can be turned either ON or OFF. The most important syntax constructs for sudoers configuration files are as follows:

# Everything on a line after # is ignored1
Defaults !insults # Disable the insults flag2
Defaults env_keep += "DISPLAY HOME" # Add DISPLAY and HOME to env_keep3
tux ALL = NOPASSWD: /usr/bin/frobnicate, PASSWD: /usr/bin/journalctl4

1

There are two exceptions: #include and #includedir are regular commands. The more current version does not use the # anymore. Instead, include directives are now preceded by @. The # notation is still supported for backward compatibility reasons.

2

Remove the ! character to set the desired flag to ON.

3

Specify a list of environment variables that should be kept when env_reset is enabled.

4

A complex rule that states that the user tux requires a password to run /usr/bin/journalctl and does not require one to run /usr/bin/frobnicate on all hosts.

Useful flags and options
targetpw

If set, sudo prompts for the user password specified in the -u option or the root password, if -u is not used. The default is ON.

Defaults targetpw # Turn targetpw flag ON
rootpw

If set, sudo prompts for the root password. The default is OFF.

Defaults !rootpw # Turn rootpw flag OFF
env_reset

If set, sudo constructs a minimal environment with TERM, PATH, HOME, MAIL, SHELL, LOGNAME, USER, USERNAME, and SUDO_*. Additionally, variables listed in env_keep are imported from the calling environment. The default is ON.

Defaults env_reset # Turn env_reset flag ON
env_keep

The list of environment variables to keep when the env_reset flag is ON.

# Set env_keep to contain EDITOR and PROMPT
Defaults env_keep = "EDITOR PROMPT"
Defaults env_keep += "JRE_HOME" # Add JRE_HOME
Defaults env_keep -= "JRE_HOME" # Remove JRE_HOME
env_delete

The list of environment variables to remove when the env_reset flag is OFF.

# Set env_delete to contain EDITOR and PROMPT
Defaults env_delete = "EDITOR PROMPT"
Defaults env_delete += "JRE_HOME" # Add JRE_HOME
Defaults env_delete -= "JRE_HOME" # Remove JRE_HOME

7.2 Basic sudoers rules

Each rule follows the following scheme ([] marks optional parts):

#Who      Where         As whom      Tag                What
User_List Host_List = [(User_List)] [NOPASSWD:|PASSWD:] Cmnd_List
sudoers rule syntax
User_List

One or several identifiers (separated by commas): either a user name, a group in the format %GROUPNAME, or a user ID in the format #UID. Negation can be specified with the ! prefix.

Host_List

One or several identifiers (separated by commas): either a (fully qualified) host name or an IP address. Negation can be specified with the ! prefix. ALL is a common choice for Host_List.

NOPASSWD:|PASSWD:

The user is not prompted for a password when running commands matching Cmd_List after NOPASSWD:.

PASSWD: is the default. It only needs to be specified when both PASSWD: and NOPASSWD: are on the same line:

tux ALL = PASSWD: /usr/bin/foo, NOPASSWD: /usr/bin/bar
Cmnd_List

One or several specifiers (separated by commas): a path to an executable, followed by an optional allowed argument.

/usr/bin/foo     # Anything allowed
/usr/bin/foo bar # Only "/usr/bin/foo bar" allowed
/usr/bin/foo ""  # No arguments allowed

ALL can be used as User_List, Host_List and Cmnd_List.

7.3 Simplify sudoers using aliases

Administrators can avoid having to maintain a set of repetitive and individual rules by introducing aliases to group items. Their syntax is the same as the syntax of the rules. The following types of aliases are supported:

User_Alias

A list of user names

Runas_Alias

A group of users by UID

Host_Alias

A list of host names

Cmnd_Alias

A list of commands and directories, and aliases

Think of aliases as named lists of users, groups, commands and hosts. To illustrate the power of aliases, take this example:

Host_Alias    WEBSERVERS = www1, www2, www31
User_Alias    ADMINS = tux, wilber, suzanne2
Cmnd_Alias    REBOOT = /sbin/halt, /sbin/reboot, /sbin/poweroff3
ADMINS WEBSERVERS = REBOOT4

1

The three servers are grouped into one Host_Alias WEBSERVERS. You can use (fully qualified) host names or IP addresses.

2

Similar to the hosts grouped above, group users or even groups of users (like %wheel) are listed here. Negation is achieved with the ! prefix, as usual.

3

Specifies a group of commands that are used in the same context.

4

All aliases are wrapped into a single rule stating that all users specified by the User_Alias can execute the group of commands specified under Cmnd_Alias on all hosts named in Host_Alias.

In summary, aliases help administrators to keep sudoers lean and manageable (and therefore secure). If, for example, one of the users has left the company, you can delete this person's name from the User_Alias statement and any system group they belonged to just once instead of having to search for all rules including this particular user.