Configuring Superuser Privileges with sudo
- WHAT?
Get familiar with the basics of
sudo
configuration and learn how to delegate superuser privileges withsudo
.- WHY?
Some commands require administrator or
root
privileges. Usingsudo
, 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 functioningsudo
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 forsudo
configuration. Learn how to work with users, user groups and aliases insudo
setups. Familiarize yourself withsudo
best practices and troubleshooting.- REQUIREMENTS
Basic understanding of
sudo
.root
privileges. For information on how to usesudo
as a normal user, refer to https://documentation.suse.com/smart/systems-management/html/sudo-run-commands-as-superuser/index.html.The sudo package needs to be installed.
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 theroot
password and switch to theroot
account.
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.
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 editsudo
configuration files Any changes to the
sudo
configuration should be done using thevisudo
command.visudo
is a tailor-made tool that allows you to edit thesudo
configuration files and runs basic syntax checks, making sure that the configuration remains intact and functional. A faultysudo
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 bysudo
. 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 before10_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.
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.
As system administrator (
root
), create a custom configuration file that holds the new user-specific directives by startingvisudo
. Use both numbering and a descriptive name:#
visudo -f /etc/sudoers.d/02_usermanagement
Create a rule that allows
tux
to execute the/usr/sbin/useradd
binary in the entire environment that thissudo
configuration is applied to:tux1 ALL2 = /usr/sbin/useradd3
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!
.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.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.
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 Enterprise Micro system. Negate it using!
to require the user to just enter their own password instead of theroot
password.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.
To modify the example configuration, open it as system administrator with
visudo
:#
visudo /etc/sudoers.d/02_usermanagement
Add more users to the rule in a comma-separated list:
tux, wilber ALL = /usr/sbin/useradd
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
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 Enterprise Micro system. Negate it using!
to require the listed users to just enter their own password instead of theroot
password.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
).
Create a new file to hold your global alias definitions:
#
visudo /etc/sudoers.d/01_aliases
Add the following line to create the
TEAMLEADERS
alias:User_Alias TEAMLEADERS = tux, wilber
Add the following line to create the
USERMANAGEMENT
alias:Cmnd_Alias USERMANAGEMENT = /usr/sbin/useradd, /usr/sbin/usermod, /usr/sbin/userdel
Save your changes and exit
visudo
.As system administrator, start
visudo
to edit the example configuration file:#
visudo -f /etc/sudoers.d/02_usermanagement
Delete the previous rule and replace it with the following rule that uses the aliases you have just defined above:
TEAMLEADERS ALL = USERMANAGEMENT
To let all the users defined by
User_Alias
use their own password instead of theroot
password, add the following line:Defaults:TEAMLEADERS !targetpw
Save the configuration, leave the editor and open a second shell to test whether
sudo
honors your new configuration.
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.
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.
sudo
password prompts #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.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 asudo
command.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 theroot
password.sudo -i
starts the shell as an interactive login shell with a clean environment. To run this command, you enter theroot
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 theroot
account by any intruder. For more information, refer to Section 3, “Changing thesudo
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 runvisudo -c
to check whether your entire framework ofsudo
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 Enterprise 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 dedicatedsudo
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
There are two exceptions: | |
Remove the | |
Specify a list of environment variables that should be kept when
| |
A complex rule that states that the user |
targetpw
If set,
sudo
prompts for the user password specified in the-u
option or theroot
password, if-u
is not used. The default is ON.Defaults targetpw # Turn targetpw flag ON
rootpw
If set,
sudo
prompts for theroot
password. The default is OFF.Defaults !rootpw # Turn rootpw flag OFF
env_reset
If set,
sudo
constructs a minimal environment withTERM
,PATH
,HOME
,MAIL
,SHELL
,LOGNAME
,USER
,USERNAME
, andSUDO_*
. Additionally, variables listed inenv_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
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 forHost_List
.NOPASSWD:|PASSWD:
The user is not prompted for a password when running commands matching
Cmd_List
afterNOPASSWD:
.PASSWD:
is the default. It only needs to be specified when bothPASSWD:
andNOPASSWD:
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
The three servers are grouped into one Host_Alias
| |
Similar to the hosts grouped above, group users or even groups of users
(like | |
Specifies a group of commands that are used in the same context. | |
All aliases are wrapped into a single rule stating that all users specified
by the |
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.
8 Legal Notice #
Copyright© 2006–2024 SUSE LLC and contributors. All rights reserved.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”.
For SUSE trademarks, see https://www.suse.com/company/legal/. All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its affiliates. Asterisks (*) denote third-party trademarks.
All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its affiliates, the authors, nor the translators shall be held liable for possible errors or the consequences thereof.