In the previous post, we talked about the Linux iptables firewall, and some people asked about authentication. Today, we will talk about the powerful framework in Linux used for authentication, which is Linux-PAM. PAM or Pluggable Authentication Modules are the management layer that sits between Linux applications and the Linux native authentication system.
There are many programs on your system that use PAM modules like su, passwd, ssh, login, and other services. We will discuss some of them.
PAM’s main focus is to authenticate your users.
Authentication in Linux is done by matching the encrypted password in /etc/shadow file with the entered one.
We have many services on our systems that require authentication like SSH, FTP, TELNET, IMAP, and many other services. So, we will have a lot of authentication files besides /etc/shadow file to maintain, and it could be a serious problem if there is any inconsistent data between these authentication files.
Here comes PAM. Linux-PAM offers a unified login system for your services.
To check if your program uses Linux-PAM or not:
$ ldd /bin/su
You should see libpam.so library.
The configuration of Linux-PAM is in the directory /etc/pam.d/.
Some PAM modules require configuration files with the PAM configuration to operate. You can find the configuration files in /etc/security.
If you misconfigure PAM, this could lead to serious problems.
The four types of PAM services:
- Authentication service modules.
- Account management modules.
- Session management modules.
- Password management modules.
Any application requires authentication can register with PAM using a service name.
You can list Linux services that use Linux-PAM.
$ ls /etc/pam.d/
If you open any service file, you will see that the file is divided into three columns. The first column is the management group, the second column is for control flags, and the third column is the module (so file) used.
$ cat /etc/pam.d/sshd
account required pam_nologin.so
The account is the management group, required is the control flag, and the used module is pam_nologin.so.
You may find a fourth column, which is for module parameters.
There are four Management Groups you will see in PAM services files:
- Auth Group: it can validate users
- Account Group: controls the access to the service like how many times you should use this service.
- Session Group: responsible for the service environment.
- Password Group: for password updating.
We have four control flags in services files:
- Requisite: the strongest flag. If the requisite not found or failed to load, it will stop loading other modules and return failure.
- Required: The same as requisite, but if the module failed to load for any reason, it continues loading other modules and returns failure at the end of execution.
- Sufficient: if the module return success, the processing of other modules no longer needed.
- Optional: In the case of failure, the stack of modules continues execution, and the return code is ignored.
The order is important because each module depends on the previous module on the stack.
If you try a configuration like the following to log in:
auth required pam_unix.so auth optional pam_deny.so
That will work correctly, but what will happen if we change the order like this:
auth optional pam_deny.so auth required pam_unix.so
No one can log in, so the order matters.
There are PAM built-in modules on your system that you should know about, so you can use them perfectly.
This module allows access for the specified groups. You can validate user accounts like this:
auth required pam_succeed_if.so gid=1000,2000
The above line states that only users in the group whose ID 1000 or 2000 are allowed to log in.
You can use uid as user id instead.
auth requisite pam_succeed_if.so uid >= 1000
In this example, any user id greater than or equal 1000 can log in.
You can also use it with ingroup parameter like this:
auth required pam_succeed_if.so user ingroup mygroup
Only people in the group named mygroup can log in.
This module allows root only to log in if the file is available.
auth required pam_nologin.so
You can modify the login service file with this line and create /etc/nologin file, so root only can log in.
And you can use it with auth, account management groups.
This module works like the pam_succeed_if module except the pam_access module checks logging from networked hosts, while the pam_succeed_if module doesn’t care.
account required pam_access.so accessfile=/etc/security/access.conf
You can type your rules in the file like this:
The above rules state that only mygroup users are allowed to log in while others can’t.
Where plus sign means allow and minus sign means deny.
This module is used with auth, account, session, password management groups.
You can use this module for restricting access. It will always return a non-OK.
You can use it at the end of your module stack to protect yourself from any misconfiguration.
If you use it at the beginning of the module stack, your service will be disabled:
auth required pam_deny.so auth required pam_unix.so
And you can use it with auth, account, session, password management groups.
You can use this module to check the user’s credentials against /etc/shadow file.
auth required pam_unix.so
You will see this module used in many services in your system.
And you can use it with auth, session, password management groups.
You can use this module to check if the user is in /etc/passwd.
account sufficient pam_localuser.so
And you can use it with auth, session, password, account management groups.
Instead of checking the user’s credentials against/etc/shadow, you can use a MySQL database as a backend using the pam_mysql module.
You can use it like this:
auth sufficient pam_mysql.so user=myuser passwd=mypassword host=localhost db=mydb table=users usercolumn=username passwdcolumn=password
Here we validate the user with the parameters for pam_mysql.
You can install if it is not on your system like this:
$ yum install libpam-mysql
We use this module with auth, session, password, account management groups.
Strong passwords are a must these days. This module ensures that you will use strong passwords.
password required pam_cracklib.so retry=4 minlen=12 difok=6
This example ensures that:
Password minimum length = 12
Four times to pick a strong password; otherwise, it will exit.
Your new password must have six new characters from the old password. You can use this module with the password management group.
This module checks if the user ID is 0, which means only root users can run this service.
auth sufficient pam_rootok.so
We use this module to ensure that a specific service is allowed for root users only, and you can use it with the auth management group.
You can use this module to set limits on the system resources. It affects even root users.
The limits configuration is in the /etc/security/limits.d/ directory.
session required pam_limits.so
You can use this module to protect your system resources, and you can use it with the session management group.
The limits in /etc/security/limits.conf file could be hard or soft.
Hard: The user cannot change its value, but root can.
Soft: normal user can change it.
The limits could be fsize, cpu, nproc, nproc, data, and many other limits.
@mygroup hard nproc 50 myuser hard cpu 5000
The first limit for mygroup members, which sets the number of processes for each one of them to be 50.
The second limit for the user named myuser, which limits the CPU time to 5000 minutes.
You can edit any PAM service file in /etc/pam.d/ and use the module you want to protect your services the way you want.
I hope you find using Linux PAM modules easy and useful.
Founder of LikeGeeks. I’m working as a Linux system administrator since 2010. I’m responsible for maintaining, securing, and troubleshooting Linux servers for multiple clients around the world. I love writing shell and Python scripts to automate my work.