To properly set the group owner of /etc/sudoers.d, run the command:
$ sudo chgrp root /etc/sudoers.d
The ownership of the /etc/sudoers.d directory by the root group is important because this directory hosts sudo configuration. Protection of this directory is critical for system security. Assigning the ownership to root ensures exclusive control of the sudo configuration.
To properly set the owner of /etc/sudoers.d, run the command:
$ sudo chown root /etc/sudoers.d
The ownership of the /etc/sudoers.d directory by the root user is important because this directory hosts sudo configuration. Protection of this directory is critical for system security. Assigning the ownership to root ensures exclusive control of the sudo configuration.
To properly set the permissions of /etc/sudoers.d, run the command:
$ sudo chmod 0750 /etc/sudoers.d
Setting correct permissions on the /etc/sudoers.d directory is important because this directory hosts sudo configuration. Protection of this directory is critical for system security. Restricting the permissions ensures exclusive control of the sudo configuration.
To properly set the group owner of /etc/sudoers, run the command:
$ sudo chgrp root /etc/sudoers
The ownership of the /etc/sudoers file by the root group is important because this file hosts sudo configuration. Protection of this file is critical for system security. Assigning the ownership to root ensures exclusive control of the sudo configuration.
To properly set the owner of /etc/sudoers, run the command:
$ sudo chown root /etc/sudoers
The ownership of the /etc/sudoers file by the root user is important because this file hosts sudo configuration. Protection of this file is critical for system security. Assigning the ownership to root ensures exclusive control of the sudo configuration.
To properly set the permissions of /etc/sudoers, run the command:
$ sudo chmod 0440 /etc/sudoers
Setting correct permissions on the /etc/sudoers file is important because this file hosts sudo configuration. Protection of this file is critical for system security. Restricting the permissions ensures exclusive control of the sudo configuration.
The sudo package can be installed with the following command:
$ sudo dnf install sudo
sudo is a program designed to allow a system administrator to give limited root privileges to users and log root activity. The basic philosophy is to give as few privileges as possible but still allow system users to get their work done.
The sudo env_reset tag, when specified, will run the command in a minimal environment, containing the TERM, PATH, HOME, MAIL, SHELL, LOGNAME, USER and SUDO_* variables. On Red Hat Enterprise Linux 10, env_reset is enabled by default This should be enabled by making sure that the env_reset tag exists in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/.
Forcing sudo to reset the environment ensures that environment variables are not passed on to the command accidentaly, preventing leak of potentially sensitive information.
The sudo ignore_dot tag, when specified, will ignore the current directory in the PATH environment variable. On Red Hat Enterprise Linux 10, ignore_dot is enabled by default This should be enabled by making sure that the ignore_dot tag exists in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/.
Ignoring the commands in the user's current directory prevents an attacker from executing commands downloaded locally.
The sudo NOEXEC tag, when specified, prevents user executed commands from executing other commands, like a shell for example. This should be enabled by making sure that the NOEXEC tag exists in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/.
Restricting the capability of sudo allowed commands to execute sub-commands prevents users from running programs with privileges they wouldn't have otherwise.
The sudo passwd_timeout tag sets the amount of time sudo password prompt waits. On Red Hat Enterprise Linux 10, the default passwd_timeout value is 5 minutes. The passwd_timeout should be configured by making sure that the passwd_timeout=$var_sudo_passwd_timeout tag exists in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/.
Reducing the time sudo waits for a a password reduces the time the process is exposed.
The sudo requiretty tag, when specified, will only execute sudo commands from users logged in to a real tty. This should be enabled by making sure that the requiretty tag exists in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/.
Restricting the use cases in which a user is allowed to execute sudo commands reduces the attack surface.
The sudo umask tag, when specified, will be added the to the user's umask in the command environment. On Red Hat Enterprise Linux 10, the default umask value is 0022. The umask should be configured by making sure that the umask=$var_sudo_umask tag exists in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/.
The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read or written to by unauthorized users.
The sudo use_pty tag, when specified, will only execute sudo commands from users logged in to a real tty. This should be enabled by making sure that the use_pty tag exists in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/.
Requiring that sudo commands be run in a pseudo-terminal can prevent an attacker from retaining access to the user's terminal after the main program has finished executing.
A custom log sudo file can be configured with the 'logfile' tag. This rule configures a sudo custom logfile at the default location suggested by CIS, which uses /var/log/sudo.log.
A sudo log file simplifies auditing of sudo commands.
Restrict the execution of privilege escalated commands to a dedicated group of users. Ensure the group owner of /usr/bin/sudo is $var_sudo_dedicated_group.
Restricting the set of users able to execute commands as privileged user reduces the attack surface.
The sudo !authenticate option, when specified, allows a user to execute commands using sudo without having to authenticate. This should be disabled by making sure that the !authenticate option does not exist in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/.
Without re-authentication, users may access resources or perform tasks for which they
do not have authorization.
When operating systems provide the capability to escalate a functional capability, it
is critical that the user re-authenticate.
The sudo NOPASSWD tag, when specified, allows a user to execute commands using sudo without having to authenticate. This should be disabled by making sure that the NOPASSWD tag does not exist in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/.
Without re-authentication, users may access resources or perform tasks for which they
do not have authorization.
When operating systems provide the capability to escalate a functional capability, it
is critical that the user re-authenticate.
The sudo NOPASSWD and !authenticate option, when specified, allows a user to execute commands using sudo without having to authenticate. This should be disabled by making sure that NOPASSWD and/or !authenticate do not exist in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/."
Without re-authentication, users may access resources or perform tasks for which they
do not have authorization.
When operating systems provide the capability to escalate a functional capability, it
is critical that the user re-authenticate.
The sudo timestamp_timeout tag sets the amount of time sudo password prompt waits. The default timestamp_timeout value is 5 minutes. The timestamp_timeout should be configured by making sure that the timestamp_timeout tag exists in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/. If the value is set to an integer less than 0, the user's time stamp will not expire and the user will not have to re-authenticate for privileged actions until the user's session is terminated.
Without re-authentication, users may access resources or perform tasks for which they
do not have authorization.
When operating systems provide the capability to escalate a functional capability, it
is critical that the user re-authenticate.
Remove the execute permission bit of /etc/bin/sudo for the other users.
To properly set the permissions of /usr/bin/sudo, run the command:
$ sudo chmod 4110 /usr/bin/sudo
Restricting the set of users able to execute commands as privileged user reduces the attack surface.
The sudo NOPASSWD tag, when specified, allows a user to execute commands using sudo without having to authenticate. Only the vdsm user should have this capability in any sudo configuration snippets in /etc/sudoers.d/.
Without re-authentication, users may access resources or perform tasks for which they
do not have authorization.
When operating systems provide the capability to escalate a functional capability, it
is critical that the user re-authenticate.
Administrators can configure authorized sudo users via drop-in files, and it is possible to include other directories and configuration files from the file currently being parsed. Make sure that /etc/sudoers only includes drop-in configuration files from /etc/sudoers.d, or that no drop-in file is included. Either the /etc/sudoers should contain only one #includedir directive pointing to /etc/sudoers.d, and no file in /etc/sudoers.d/ should include other files or directories; Or the /etc/sudoers should not contain any #include, @include, #includedir or @includedir directives. Note that the '#' character doesn't denote a comment in the configuration file.
Some sudo configurtion options allow users to run programs without re-authenticating. Use of these configuration options makes it easier for one compromised accound to be used to compromise other accounts.
All commands in the sudoers file must strictly specify the arguments allowed to be used for a given user. If the command is supposed to be executed only without arguments, pass "" as an argument in the corresponding user specification.
Any argument can modify quite significantly the behavior of a program, whether regarding the realized operation (read, write, delete, etc.) or accessed resources (path in a file system tree). To avoid any possibility of misuse of a command by a user, the ambiguities must be removed at the level of its specification. For example, on some systems, the kernel messages are only accessible by root. If a user nevertheless must have the privileges to read them, the argument of the dmesg command has to be restricted in order to prevent the user from flushing the buffer through the -c option:
user ALL = dmesg ""
Policies applied by sudo through the sudoers file should not involve negation.
Each user specification in the sudoers file contains a comma-delimited list of command specifications.
The definition can make use glob patterns, as well as of negations.
Indirect definition of those commands by means of exclusion of a set of commands is trivial to bypass, so it is not allowed to use such constructs.
Specifying access right using negation is inefficient and can be easily circumvented. For example, it is expected that a specification like
# To avoid absolutely , this rule can be easily circumvented! user ALL = ALL ,!/ bin/shprevents the execution of the shell but that’s not the case: just copy the binary
/bin/sh to a different name to make it executable
again through the rule keyword ALL.
The targeted users of a user specification should be, as much as possible, non privileged users (i.e.: non-root). User specifications have to explicitly list the runas spec (i.e. the list of target users that can be impersonated), and ALL or root should not be used.
It is common that the command to be executed does not require superuser rights (editing a file whose the owner is not root, sending a signal to an unprivileged process,etc.). In order to limit any attempt of privilege escalation through a command, it is better to apply normal user rights.
The sudoers security policy requires that users authenticate themselves before they can use sudo. When sudoers requires authentication, it validates the invoking user's credentials. The expected output for:
sudo cvtsudoers -f sudoers /etc/sudoers | grep -E '^Defaults !?(rootpw|targetpw|runaspw)$'
Defaults !targetpw
Defaults !rootpw
Defaults !runaspw
or if cvtsudoers not supported:
sudo find /etc/sudoers /etc/sudoers.d \( \! -name '*~' -a \! -name '*.*' \) -exec grep -E --with-filename '^[[:blank:]]*Defaults[[:blank:]](.*[[:blank:]])?!?\b(rootpw|targetpw|runaspw)' -- {} \;
/etc/sudoers:Defaults !targetpw
/etc/sudoers:Defaults !rootpw
/etc/sudoers:Defaults !runaspw
If the rootpw, targetpw, or runaspw flags are defined and not disabled, by default the operating system will prompt the invoking user for the "root" user password.
To properly set the permissions of /usr/bin/sudo, run the command:
$ sudo chmod 4111 /usr/bin/sudo
The sudoers program should only be usable by people who have the correct permissions.