Password Security & Sudoers
Last updated
Last updated
Any changes made to /etc/login.defs will only be applied if the usermod command is used. If user IDs are added a different way, use the chage command to effect changes to individual user IDs.
The su command allows a user to run a command or shell as another user. The program has been superseded by sudo , which allows for more granular control over privileged access. Normally, the su command can be executed by any user. By uncommenting the pam_wheel.so statement in /etc/pam.d/su , the su command will only allow users in the wheel group to execute su .
Add the following line to the /etc/pam.d/su file:
Create a comma separated list of users in the wheel statement in the /etc/group file:
Set the PASS_MAX_DAYS parameter to conform to site policy in /etc/login.defs :
Modify user parameters for all users with a password set to match:
You can also check this setting in /etc/shadow directly. The 5th field should be 365 or less for all users with a password.
A value of -1 will disable password expiration. Additionally the password expiration must be greater than the minimum days between password changes or users will be unable to change their password.
The PASS_MIN_DAYS parameter in /etc/login.defs allows an administrator to prevent users from changing their password until a minimum number of days have passed since the last time the user changed their password. It is recommended that PASS_MIN_DAYS parameter be set to 7 or more days
Set the PASS_MIN_DAYS parameter to 7 in /etc/login.defs :
Modify user parameters for all users with a password set to match
You can also check this setting in /etc/shadow directly. The 4th field should be 7 or more for all users with a password.
The PASS_WARN_AGE parameter in /etc/login.defs allows an administrator to notify users that their password will expire in a defined number of days. It is recommended that the PASS_WARN_AGE parameter be set to 7 or more days.
Set the PASS_WARN_AGE parameter to 7 in /etc/login.defs :
Modify user parameters for all users with a password set to match:
You can also check this setting in /etc/shadow directly. The 6th field should be 7 or more for all users with a password.
User accounts that have been inactive for over a given period of time can be automatically disabled. It is recommended that accounts that are inactive for 30 days after password expiration be disabled.
find these accounts with:
Run the following command to set the default password inactivity period to 30 days:
Modify user parameters for all users with a password set to match:
Edit the /etc/bashrc and /etc/profile files (and the appropriate files for any other shell supported on your system) and add or edit any umask parameters as follows:
The audit and remediation in this recommendation apply to bash and shell. If other shells are supported on the system, it is recommended that their configuration files also are checked. Other methods of setting a timeout exist for other shells not covered here.
The file /etc/securetty contains a list of valid terminals that may be logged in directly as root.
Add the following line to the /etc/pam.d/su file:
Create a comma separated list of users in the wheel statement in the /etc/group file:
An account with an empty password field means that anybody may log in as that user without providing a password.
Run the following command and verify that no output is returned:
If any accounts in the /etc/shadow file do not have a password, run the following command to lock the account until it can be determined why it does not have a password:
The root user can execute any command on the system and could be fooled into executing programs unintentionally if the PATH is not set correctly.
Including the current working directory (.) or other writable directory in root 's executable path makes it likely that an attacker can gain superuser access by forcing an administrator operating as root to execute a Trojan horse program.
Run the following script and verify no results are returned:
Correct or justify any items discovered in the Audit step.
The easiest way of doing this on a system set up with a general purpose administration group, like the Ubuntu system in this guide, is actually to just add the user in question to that group.
The gpasswd command can also be used:
On CentOS, this is usually the wheel group instead of the sudo group:
Or, using gpasswd:
/etc/sudoersNever edit this file with a normal text editor! Always use the visudo command instead!
Because improper syntax in the /etc/sudoers file can leave you with a system where it is impossible to obtain elevated privileges, it is important to use the visudo command to edit the file.
The visudo command opens a text editor like normal, but it validates the syntax of the file upon saving. This prevents configuration errors from blocking sudo operations, which may be your only way of obtaining root privileges.
If you would like to change the editor ssue the following command:
The first line, “Defaults env_reset”, resets the terminal environment to remove any user variables. This is a safety measure used to clear potentially harmful environmental variables from the sudo session.
The second line, Defaults mail_badpass, tells the system to mail notices of bad sudo password attempts to the configured mailto user. By default, this is the root account.
The third line, which begins with “Defaults secure_path=…”, specifies the PATH (the places in the filesystem the operating system will look for applications) that will be used for sudo operations. This prevents using user paths which may be harmful.
The fourth line, , which dictates the root user’s sudo privileges, is different from the preceding lines. Let’s take a look at what the different fields mean:
format:
root ALL=(ALL:ALL) ALL
The first field indicates the username that the rule will apply to (root).
demo ALL=(ALL:ALL) ALL
The first “ALL” indicates that this rule applies to all hosts.
demo ALL=(ALL:ALL) ALL
This “ALL” indicates that the root user can run commands as all users.
demo ALL=(ALL:ALL) ALL
This “ALL” indicates that the root user can run commands as all groups.
demo ALL=(ALL:ALL) ALL
The last “ALL” indicates these rules apply to all commands. This means that our root user can run any command using sudo, as long as they provide their password.
The sudoers file can be organized more easily by grouping things with various kinds of “aliases”.
For instance, we can create three different groups of users, with overlapping membership:
Group names must start with a capital letter. We can then allow members of GROUPTWO to update the apt database by creating a rule like this:
If we do not specify a user/group to run as, as above, sudo defaults to the root user.
We can allow members of GROUPTHREE to shutdown and reboot the machine by creating a “command alias” and using that in a rule for GROUPTHREE:
We create a command alias called POWER that contains commands to power off and reboot the machine. We then allow the members of GROUPTHREE to execute these commands.
We can also create “Run as” aliases, which can replace the portion of the rule that specifies the user to execute the command as:
This will allow anyone who is a member of GROUPONE to execute commands as the www-data user or the apache user.
If we want to allow users to execute it with root privileges without having to type a password, we can make a rule like this:
A tag is relevant for the rest of the rule unless overruled by its “twin” tag later down the line.
Another helpful tag is NOEXEC, which can be used to prevent some dangerous behavior in certain programs.
For example, some programs, like “less”, can spawn other commands by typing this from within their interface:
This basically executes any command the user gives it with the same permissions that “less” is running under, which can be quite dangerous.
To restrict this, we could use a line like this:
In order to set a different timeout (globally) than the default (=15 min) you can edit /etc/sudoers:
or:
Special values:
-1: no timeout
0: get prompted every single time
Certain programs, especially text editors and pagers, have a handy shell escape feature. This allows a user to run a shell command without having to exit the program first.
nano
vi
vim
less
emacs
view
more
...
to prevent user from shell escape with text editors, give them sudo permissions for sudoedit only, sudoedit has no shell escape feature
Let's say that you create a sudo rule so that Sylvester can use the systemctl command:
This allows Sylvester 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 Sylvester is allowed to do. Let's say that you want him to be able to control just the Secure Shell service.
he syntax would be like this:
You can make the line look like this:
Sylvester 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 Sylvester 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 Sylvester to do:
Now, Sylvester can only restart the Secure Shell service or check its status.
