PAM (Pluggable Authentication Module)

Author(s): Kirill Shore

Last Updated: 10-02-2025

Recommended Prerequisites (click to expand)

None

What is PAM?

PAM stands for Pluggable Authentication Module. It's a framework that provides important ways to create authentication (and related) programs indipendently of the applications that use them. PAM may be used to handle tasks like verifying a username and password, checking biometric data, or working with external systems like Kerberos, LDAP, or 2FA. PAM systems administartors have the ability to then plug in different authentication module methods (like 2FA) without changing/rewriting applications/programs. I.e. you may switch from password authentication to security keys. Fun fact: the applications themselves don't know how authentication is performed. The only thing they do is ask pam if the user is who they claim to be.

Pam Basics

There are several PAM services (not to be confused with modules), as an example:

sshd, which handles authentication for remote logins via SSH. It validates credentials like passwords, keys, MFA, etc., enforces different policies like banning the ability to login as root, or requiring 2FA. It can also prevent brute force attempts when combined with modules like pam_tally2.
login, it controls authentication for users who are logging in via a text console (i.e. tty). It verifies the username and password, checks if the account is locked/expired, and applies restrictions like time of day logins.
sudo, manages authentication when a user attempts to run commands as another user (i.e. su). It prompts the user for password before escalating privelages. It also has the ability to timeout someone who is root and force them to re-login. On many distros, su cannot be run alone to switch to root, as the root account is disabled by default (meaning its password is locked). Sudo su is instead used. Sudo checks if your user in the sudo or wheel group, asks for your password, and then runs su as root so that there is no need for a root password. Each PAM service also has its own file in /etc/pam.d. These files define which modules are being user (modules are shared libraries that perform special security functions, such as user authetication, account management, session management, or password management). Some PAM modules are, but not limited to:
pam_unix.so (Default PAM module)
pam_tally2.so (Which is used to count login attempts and lock an account after a specified number of failed attempts)
pam_google_authenticator.so (Which provides 2FA support if you use the Google Authenticator app on a mobile device)

PAM Security Principles

In any Cybersecurity industry, the idea of Least Privilege is important, in order to prevent users from having more power than they need. For example, a teller for FreedomBank has to process a transaction, depositing phyisical cash and adding it to the customers bank account. This employee should not, nor do they need, access to information (unless for verification purposes) such as the tiles or details of past transactions other than their amounts, investment accounts, debts or loans, etc. In this case, the teller is given the minimum privileges to do their job, and nothing more. But how can PAM be used in this case? Let's suppose that the teller logs into a banking application or a Linux shell for deposits. In /etc/pam.d/deposit_app, we would configure PAM to allow teller group users or higher to authenticate:

auth	required	pam_unix.so
account	required	pam_succeed_if.so	user	ingroup	tellers

(Note that the above is a basic configuration that will ONLY allow tellers to login. An example of a more realistic configuration is below)

auth    required	pam_faillock.so	preauth	silent	deny=5	unlock_time=600 # (this would lockout the account to prevent brute-force attacks
auth	required	pam_unix.so try_first_pass # (primary password authentication)
auth	required	pam_u2f.so	authfile=/etc/security/u2f_mappings	cue # (this would require 2FA via FIDO/U2F security key, and store mappings in /etc/security/u2f_mappings)
auth	required	pam_faillock.so	authfail # (count failures, records them in /var/run/faillock. If the amount of failures exceeds the threshold, the account is locked for the configured time)
auth	sufficient	pam_faillock.so	reset # (If this module succeeds---thus the user authenticates---then it clears any failed login attempts for that user, and resest the counter to 0 for that user)

PAM Control Flags and Keywords

Now, you may be asking: what do those flags, like auth, required, sufficient and etc. mean? Well, these words are PAM control flags, and they decide when a specific module is invoked, how its result is interpreted, and whwether or not pam keeps processing.

First, there are the facility keywords. These keyowrds tell PAM which phase or type of check the line belongs to.

auth -> This verifies a users identity (i.e. Password check, 2FA, smartcard)
account -> This determines if the account is allowed access. (i.e. Is the account expired? Is the user allowed to login from 21:00-08:00?)
password -> This handles changing or updating credentials. (i.e. Enforcing strong password rules when a user runs the command passwd)
session -> This manages session startup and shutdown. (i.e. Logging session start/stop, mounting home directiories, applying resource limits)

Next, we have the control flags. These define what pam should do with the results of the module.

required -> This instructs that the module must succeed in order for authentication to succeed. However, if the module fails, PAM will continue processing, to prevent the user from knowing which check had failed. If any required module fails, the outcome will be fail, no matter if other modules succeeded.
requisite -> This is mostly the same as required above. However, instead of continuing upon failure, PAM will stop immediatley and deny access.
sufficient -> If the module succeeds, no further checks are required, and access will be immediatley granted. However, if the module fails, then PAM will keep going.
optional -> Whether or not the success or failure of that module will be considered is if it is the only module of that type. Otherwise, it'll be ignored. This is mainly used for logging modules and non-critical checks.
include -> This isn't a flag, but actually a directive. It means 'include another PAM configuration file here'. It is mostly used for reusing common configurations.

PAM Modules

Most linux systems come pre-installed with PAM and some modules, whcih are commonly located in /lib/x86_64-linux-gnu/security/ (on Debian/Ubuntu distros; path will/,ay differ on others). Below is a list of common modules, what each of them do, and vulnerabilities/misconfigurations.

pam_unix Handles traditional UNIX authentication (passwords stored in /etc/passwd or /etc/shadow). Vulnerability: If the passwords in /etc/shadow are compromised, or weak passwords are used, threat actors can brute force credentials.
pam_cracklib/pam_pwquality Enforces password strength rules (length, complexity, dictionary checks). Vulnerability: If module isn't used, weak passwords will be used. If misconfigured, the rules may bee too relaxed (meaning simple passwords) or too strict (meaning passwords complex enough that most users would write their passwords on a sticky note... which they would stick to their monitor).
pam_limits Applies limits defined in /etc/security/limits.conf (i.e., max processes, file sizes). Vulenrability: Weak or missing limits will allow Denial of Service (Dos) via fork bombs or resource exhaustion.
pam_securetty Restricts root login to "secure" terminals that are listed in /etc/securetty. Vulnerability: If misconfigured, threat actors could login as root from unsafe terminals (i.e. remote consoles).
pam_nologin Blocks non-root users from logging in if /etc/nologin exists (can be used when editing an account to prevent access to it during a timeframe when root permissions are being changed, i.e. an employee being demoted in a company). Vulnerability: If neglected, it may unintentionally lock out legitimate users, or vice-versa not be deployed when it should've been.
pam_time Restricts logins based on time of day rules in /etc/security/time.conf. Vulnerability: Misconfiguration could allow off hours logins to systems when it should be denied (i.e. a bank representative accessing users' accounts at 2am).
pam_access Controls access based on user and host rules from /etc/security/accesss.conf. Vulnerability: Misconfiguration can grant the wrong users access and deny access to the users that need it.
pam_tally/pam_tally2/pam_faillock Counts failed login attempts and can lock accounts after there were too many failed attempts. Vulnerability: pam_tally and pam_tally2 have been deprecated due to counting errors, possible username leakage, and more. Replaced with pam_faillock.
pam_wheel Restricts the su command to users in the wheel (also called sudo) group. Vulnerability: Exploiting CVE-2003-0388 could allow a threat actor to gain wheel/sudo privilages, then modify files like sudo, login, or pam_exec.
pam_exec Runs an external program or script during authentication. Vulnerability: Misconfiguration may result in running incorrect programs during authentication.
pam_systemd Integrates uers sessions with systmd. Vulneravility: could be exploited to read coredump information, which may include /etc/shadow. CVE-2025-4598.
pam_xauth Handles X11 forwarding authentication for X11 graphical sessions. Vulnerability: If misconfigured, an insecure forwarding setup may allow X11 session hijacking.
pam_umask Sets the default file creation permissions (umask) for users. Vulnerability: if minimum permissions are not implemented, users may be able to create world-readable files that leak data (i.e., private keys and SSH data like ~/.ssh/id_rsa).
pam_group Assigns users to groups at login based on rules. Vulnerability: Misconfiguration could result in users being granted unintended group privilages.

Practice

Can you instruct PAM to have a user login, verify via Google authenticator (pam_google_authenticator.so), and solve a Captcha (/usr/local/sbin/pam_captcha.sh) before being granted access? If the user fails the captcha three times, the account is immediatley locked.

Solution (click to expand)

auth	required	pam_faillock.so preauth	silent deny=3	unlock_time=900
auth	required	pam_unix.so	try_first_pass
auth	required	pam_google_authenticator.so
auth	required	pam_exec.so	quiet	log=/var/log/pam_captcha.log seteuid /usr/local/sbin/pam_captcha.sh
auth	required	pam_faillock.so	authfail
auth	sufficient	pam_faillock.so reset

Explanation (click to expand)

The first line is a pre-auth. It defines that after 3 total auth failures, the account will be locked.
The second line defines that the primary authentication factor that must be met is the password.
The third line defines that the secondary authentication factor that must be met is getting a code from Google Authenticator.
The fourth line executes a captcha via an external script, and the script will pass to PAM whether or not it failed.
The fith line counts failures.
The sixth line resets the failure counter upon success.

Open-ended question:

Why do you think required was used instead of requisite?

PAM Vulnerabilites

Although PAM seems to be a very straightforward and secure authentication method, it introduces serious security risks if it is not managed correctly.

Most exploits boil down to attackers using malicious module to create backdoors. Because PAM modules run with higher privileges, any compromised or malicious modules can log credentials, grant unauthorized access, or lock out accounts. Current PAM vulnerabilites can be found here.

PAM Auditing

/usr/lib64/security
/etc/pam.d
/etc/security
/var/log/secure

My wesbite

Buy me a coffee

What is PAM?​

Pam Basics​

PAM Security Principles​

PAM Control Flags and Keywords​

PAM Modules​

Practice​

PAM Vulnerabilites​

PAM Auditing​

Further Reading​