An introduction to Pluggable Authentication Modules (PAM) in Linux
Pluggable Authentication Modules (PAM) have been around since 1997. I was taught that PAM originated from Sun's Solaris, and it does appear that the first enterprise use and popularization occurred there. However, according to a 1997 article I found, the first full implementation was the Linux-PAM deployment. The article is still available from Linux Journal. The basic premise and implementation have not changed since then. There are some new keywords and many new modules, but overall the process is the same as 20 years ago.
As the A in PAM indicates, PAM is about authentication. In most cases, when you log in to a system via a console or from across the network with SSH or Cockpit, PAM is involved. It doesn't matter if the user accounts are held locally or in a centralized location. For as much as it is used, it not common to manipulate the PAM configuration files directly. Other utilities do it for you. Many changes are made at installation, such as when installing the
sssd RPM or using the
ipa-client-install utility. The most common additional configurations can be handled by
authconfig (RHEL7 and older) or
authselect (RHEL8), or even through the Cockpit web interface. Most administrators do not learn about PAM configuration files until they get involved in advanced authentication and security topics.
What do we gain with PAM?
PAM separates the standard and specialized tasks of authentication from applications. Programs such as
ftpd, and many more all want to know that a user is who they say they are, yet there are many ways to do that. A user can provide a user name and password credential which can be stored locally or remotely with LDAP or Kerberos. A user can also provide a fingerprint or a certificate as a credential. It would be painful to ask each application developer to rewrite the authentication checks for each new method. A call to PAM libraries leaves the checks to authentication experts. PAM is pluggable in that we can have different applications run different tests and modular in that we can add new methods with new libraries.
Let's look at the high-level steps taken when a locally-defined user logs into a text-based console:
- The login application prompts for a user name and password, then makes a
libpamauthentication call to ask, "Is this user who they say they are?" The
pam_unixmodule is responsible for checking the local account authentication. Other modules may also be checked, and ultimately the result is passed back to the login process.
- The login process next asks, "Is this user allowed to connect?", then makes an account call to
pam_unixmodule checks for things like whether the password has expired. Other modules might check host or time-based access control lists. An overall response is handed back to the process.
- If the password has expired, the application responds. Some applications simply fail to log in the user. The login process prompts the user for a new password.
- To get the password verified and written to the correct location, the login process makes a password call to
pam_unixmodule writes to the local shadow file. Other modules may also be called to verify the password strength.
- If the login process is continuing at this point, it is ready to create the session. A session call to
libpamresults in the
pam_unixmodule writing a login timestamp to the wtmp file. Other modules enable X11 authentication or SELinux user contexts.
- On logout, when the session is closed, another session call can be made to
libpam. This is when the
pam_unixmodule writes the logout timestamp to the wtmp file.
There are many components to PAM
If you make a change to authentication using a program such as
authselect and want to see what changed, here are some of the places to look:
A collection of PAM libraries that perform various checks. Most of these modules have man pages to explain the use case and options available.
A collection of configuration files for applications that call
libpam. These files define which modules are checked, with what options, in which order, and how to handle the result. These files may be added to the system when an application is installed and are frequently edited by other utilities.
Since there are several checks done by all applications, these files may also have include statements to call other configuration files in this directory. Most shared modules are found in the system-auth file for local authentication and the password-auth file for applications listening for remote connections.
A collection of additional configuration files for specific modules. Some modules, such as
pam_time, allow additional granularity for checks. When an application configuration file calls these modules, the checks are completed using the additional information from its corresponding supplemental configuration files. Other modules, like
pam_pwquality, make it easier for other utilities to modify the configuration by placing all the options in a separate file instead of on the module line in the application configuration file.
Most security and authentication errors are reported to this log file. Permissions are configured on this file to restrict access.
This man page describes the overall process, including the types of calls and a list of files involved.
This man page describes the overall format and defines keywords and fields for the
pam.d configuration files.
man -k pam_
This search of man pages lists pages available for modules installed.
PAM allows for a much more robust authentication environment than per-application services could provide. It has been in Linux for many, many years, and is involved with nearly all user identification processes.
In the next article, I will walk through the format of the
/etc/pam.d configuration files.
[ Free online course: Red Hat Enterprise Linux technical overview. ]