This is a set of rules defined in some files, which have to be followed when a system user is setting up. It's an important factor in security because one of the many security breach histories was started with hacking user passwords. This is the reason why most organizations set a password policy for their users. All users and passwords must comply with this.

A password policy usually is defined by the following:

Password aging and password length are defined in /etc/login.defs. Aging basically means the maximum number of days a password might be used, minimum number of days allowed between password changes, and number of warnings before the password expires. Length refers to the number of characters required for creating the password. To configure password aging and length, we should edit the /etc/login.defs file and set different PASS values according to the policy set by the organization.

Let's take a look at a sample configuration of the login.defs file:

By editing the /etc/pam.d/system-auth file, we can configure the password complexity and the number of reused passwords to be denied. Password complexity refers to the complexity of the characters used in the password, and the reused password deny refers to denying the desired number of passwords the user used in the past. By setting the complexity, we force the usage of the desired number of capital characters, lowercase characters, numbers, and symbols in a password. The password will be denied by the system until and unless the complexity set by the rules is met. We do this using the following terms:

Let's now take a look at a sample configuration of /etc/pam.d/system-auth:

We set the number of login failures allowed by a user in the /etc/pam.d/password-auth, /etc/pam.d/system-auth, and /etc/pam.d/login files. When a user's failed login attempts are higher than the number defined here, the account is locked and only a system administrator can unlock the account. To configure this, make the following additions to the files. The following deny=X parameter configures this, where X is the number of failed login attempts allowed.

Add these two lines to the /etc/pam.d/password-auth and /etc/pam.d/system-auth files and only the first line to the /etc/pam.d/login file:

auth        required    pam_tally2.so file=/var/log/tallylog deny=3 no_magic_root unlock_time=300
account     required    pam_tally2.so

The following screenshot is a sample /etc/pam.d/system-auth file:

The following is a sample /etc/pam.d/login file:

To see failures, use the following command:

pam_tally2 –user=<User Name>

To reset the failure attempts and to enable the user to log in again, use the following command:

pam_tally2 –user=<User Name> --reset

The sudo is modified or implemented using the /etc/sudoers file, and visudo is the command that enables us to edit the file.

The visudo command opens a text editor normally, but then validates the syntax of the file upon saving. This prevents configuration errors from blocking sudo operations.

By default, visudo opens the /etc/sudoers file in vi editor, but we can configure it to use the nano text editor instead. For that, we have to make sure nano is already installed or we can install nano using:

yum install nano -y

Now, we can change it to use nano by editing the ~/.bashrc file:

export EDITOR=/usr/bin/nano

Then, source the file using:

. ~/.bashrc

Now, we can use visudo with nano to edit the /etc/sudoers file. So, let's open the /etc/sudoers file using visudo and learn a few things.

We can use different kinds of aliases for different sets of commands, software, services, users, groups, and so on. For example:

Cmnd_Alias NETWORKING = /sbin/route, /sbin/ifconfig, /bin/ping, /sbin/dhclient, /usr/bin/net, /sbin/iptables, /usr/bin/rfcomm, /usr/bin/wvdial, /sbin/iwconfig, /sbin/mii-tool
Cmnd_Alias SOFTWARE = /bin/rpm, /usr/bin/up2date, /usr/bin/yum
Cmnd_Alias SERVICES = /sbin/service, /sbin/chkconfig

We can use these aliases to assign a set of command execution rights to a user or a group. For example, if we want to assign the NETWORKING set of commands to the group netadmin we will define:

%netadmin ALL = NETWORKING

Otherwise, if we want to allow the wheel group users to run all the commands, we will do the following:

%wheel  ALL=(ALL)  ALL

If we want a specific user, john, to get access to all commands, we will do the following:

john  ALL=(ALL)  ALL

We can create different groups of users, with overlapping membership:

User_Alias      GROUPONE = abby, brent, carl
User_Alias      GROUPTWO = brent, doris, eric,
User_Alias      GROUPTHREE = doris, felicia, grant

Group names must start with a capital letter. We can then allow members of GROUPTWO to update the yum database and all the commands assigned to the preceding software by creating a rule like this:

GROUPTWO    ALL = SOFTWARE

If we do not specify a user/group to run, sudo defaults to the root user.

We can allow members of GROUPTHREE to shut down and reboot the machine by creating a command alias and using that in a rule for GROUPTHREE:

Cmnd_Alias      POWER = /sbin/shutdown, /sbin/halt, /sbin/reboot, /sbin/restart
GROUPTHREE  ALL = POWER

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 Runas aliases, which can replace the portion of the rule that specifies to the user to execute the command as:

Runas_Alias     WEB = www-data, apache
GROUPONE    ALL = (WEB) ALL

This will allow anyone who is a member of GROUPONE to execute commands as the www-data user or the apache user.

Just keep in mind that later, rules will override previous rules when there is a conflict between the two.

There are a number of ways that you can achieve more control over how sudo handles a command. Here are some examples:

The updatedb command associated with the mlocate package is relatively harmless. 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:

GROUPONE    ALL = NOPASSWD: /usr/bin/updatedb

NOPASSWD is a tag that means no password will be requested. It has a companion command called PASSWD, which is the default behavior. A tag is relevant for the rest of the rule unless overruled by its twin tag later down the line.

For instance, we can have a line like this:

GROUPTWO    ALL = NOPASSWD: /usr/bin/updatedb, PASSWD: /bin/kill 

In this case, a user can run the updatedb command without a password as the root user, but entering the root password will be required for running the kill command. Another helpful tag is NOEXEC, which can be used to prevent some dangerous behavior in certain programs.

For example, some programs, such as less, can spawn other commands by typing this from within their interface:

!command_to_run

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:

username    ALL = NOEXEC: /usr/bin/less

You should now have clear understanding of what sudo is and how we modify and provide access rights using visudo. There are many more things left here. You can check the default /etc/sudoers file, which has a good number of examples, using the visudo command, or you can read the sudoers manual as well.

One point to remember is that root privileges are not given to regular users often. It is important for us to understand what these commands do when you execute with root privileges. Do not take the responsibility lightly. Learn the best way to use these tools for your use case, and lock down any functionality that is not needed.