View source for PAM (Pluggable Authentication Module)

{{Submit}}
<!-- Migrated from https://cypat.guide/docs/linux/account_policies/pam (source: docs/linux/account_policies/pam.md) -->
<!-- REVIEW: source used JSX (JSX style object); layout-only divs were dropped. Compare with the original. -->
-----

Author(s): Kirill Shore

Last Updated: 10-02-2025

{| class="mw-collapsible mw-collapsed wikitable" style="width:100%"
! 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:

* <code>sshd</code>, 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.
* <code>login</code>, 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.
* <code>sudo</code>, 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 <code>/etc/pam.d</code>. 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:
* <code>pam_unix.so</code> (Default PAM module)
* <code>pam_tally2.so</code> (Which is used to count login attempts and lock an account after a specified number of failed attempts)
* <code>pam_google_authenticator.so</code> (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 <code>/etc/pam.d/deposit_app</code>, we would configure PAM to allow teller group users or higher to authenticate:

<syntaxhighlight lang="text">auth    required    pam_unix.so
account required    pam_succeed_if.so   user    ingroup tellers</syntaxhighlight>
(Note that the above is a basic configuration that will ONLY allow tellers to login. An example of a more realistic configuration is below)

<syntaxhighlight lang="text">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)</syntaxhighlight>
== PAM Control Flags and Keywords ==

Now, you may be asking: what do those flags, like <code>auth</code>, <code>required</code>, <code>sufficient</code> 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.

* <code>auth</code> -&gt; This verifies a users identity (i.e. Password check, 2FA, smartcard)
* <code>account</code> -&gt; 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?)
* <code>password</code> -&gt; This handles changing or updating credentials. (i.e. Enforcing strong password rules when a user runs the command <code>passwd</code>)
* <code>session</code> -&gt; 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.

* <code>required</code> -&gt; 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 <code>required</code> module fails, the outcome will be fail, no matter if other modules succeeded.
* <code>requisite</code> -&gt; This is mostly the same as <code>required</code> above. However, instead of continuing upon failure, PAM will stop immediatley and deny access.
* <code>sufficient</code> -&gt; 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.
* <code>optional</code> -&gt; 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.
* <code>include</code> -&gt; 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 <code>/lib/x86_64-linux-gnu/security/</code> (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.

* <code>pam_unix</code> Handles traditional UNIX authentication (passwords stored in <code>/etc/passwd</code> or <code>/etc/shadow</code>). Vulnerability: If the passwords in <code>/etc/shadow</code> are compromised, or weak passwords are used, threat actors can brute force credentials.
* <code>pam_cracklib</code>/<code>pam_pwquality</code> 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).
* <code>pam_limits</code> Applies limits defined in <code>/etc/security/limits.conf</code> (i.e., max processes, file sizes). Vulenrability: Weak or missing limits will allow Denial of Service (Dos) via fork bombs or resource exhaustion.
* <code>pam_securetty</code> Restricts <code>root</code> login to &quot;secure&quot; terminals that are listed in <code>/etc/securetty</code>. Vulnerability: If misconfigured, threat actors could login as root from unsafe terminals (i.e. remote consoles).
* <code>pam_nologin</code> Blocks non-root users from logging in if <code>/etc/nologin</code> 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.
* <code>pam_time</code> Restricts logins based on time of day rules in <code>/etc/security/time.conf</code>. Vulnerability: Misconfiguration could allow off hours logins to systems when it should be denied (i.e. a bank representative accessing users' accounts at 2am).
* <code>pam_access</code> Controls access based on user and host rules from <code>/etc/security/accesss.conf</code>. Vulnerability: Misconfiguration can grant the wrong users access and deny access to the users that need it.
* <code>pam_tally</code>/<code>pam_tally2</code>/<code>pam_faillock</code> Counts failed login attempts and can lock accounts after there were too many failed attempts. Vulnerability: <code>pam_tally</code> and <code>pam_tally2</code> have been deprecated due to counting errors, possible username leakage, and more. Replaced with <code>pam_faillock</code>.
* <code>pam_wheel</code> Restricts the <code>su</code> command to users in the <code>wheel</code> (also called <code>sudo</code>) group. Vulnerability: Exploiting [https://nvd.nist.gov/vuln/detail/CVE-2003-0388 CVE-2003-0388] could allow a threat actor to gain <code>wheel</code>/<code>sudo</code> privilages, then modify files like <code>sudo</code>, <code>login</code>, or <code>pam_exec</code>.
* <code>pam_exec</code> Runs an external program or script during authentication. Vulnerability: Misconfiguration may result in running incorrect programs during authentication.
* <code>pam_systemd</code> Integrates uers sessions with systmd. Vulneravility: could be exploited to read coredump information, which may include <code>/etc/shadow</code>. [https://nvd.nist.gov/vuln/detail/CVE-2025-4598 CVE-2025-4598].
* <code>pam_xauth</code> Handles X11 forwarding authentication for X11 graphical sessions. Vulnerability: If misconfigured, an insecure forwarding setup may allow [https://www.tenable.com/plugins/nessus/31737?utm_source=chatgpt.com X11 session hijacking].
* <code>pam_umask</code> 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).
* <code>pam_group</code> 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 (<code>pam_google_authenticator.so</code>), and solve a Captcha (<code>/usr/local/sbin/pam_captcha.sh</code>) before being granted access? If the user fails the captcha three times, the account is immediatley locked.

{| class="mw-collapsible mw-collapsed wikitable" style="width:100%"
! Solution (click to expand)
|-
|

<syntaxhighlight lang="text">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</syntaxhighlight>
|}

{| class="mw-collapsible mw-collapsed wikitable" style="width:100%"
! Explanation (click to expand)
|-
|

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

'''Open-ended question:'''<br />

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

'''Open-ended question:'''<br />

Why do you think <code>required</code> was used instead of <code>requisite</code>?

|}

== 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 [https://www.broadcom.com/support/security-center/protection-bulletin/plague-a-linux-backdoor 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 [https://www.cve.org/CVERecord/SearchResults?query=pam+linux here].

== PAM Auditing ==

* <code>/usr/lib64/security</code>
* <code>/etc/pam.d</code>
* <code>/etc/security</code>
* <code>/var/log/secure</code>

[https://www.kirillshore.com My wesbite]

[https://buymeacoffee.com/kirillshore Buy me a coffee]

== Further Reading ==

https://www.redhat.com/en/blog/pam-configuration-file<br />
https://www.redhat.com/en/blog/pluggable-authentication-modules-pam<br />
https://unit42.paloaltonetworks.com/linux-pam-apis/<br />
https://www.broadcom.com/support/security-center/protection-bulletin/plague-a-linux-backdoor<br />
https://www.cyberark.com/resources/blog/plague-malware-exploits-pluggable-authentication-module-to-breach-linux-systems

-----

<small>This Wiki page was authored by Kirill Shore. Within cypat.guide, this content is licensed under CC-BY 4.0. All use outside of cypat.guide is governed by the Shore-Roger Enterprises End User License Agreement (https://www.kirillshore.com/eula). Proper attribution to Kirill Shore as the original author is required. Unauthorized copying, modification, or redistribution without appropriate credit constitutes plagiarism and may be subject to U.S. copyright law.</small>

[[Category:Linux Account Policies|025]]
[[Category:Migrated from cypat.guide]]