Day 5: PAM

PAM (Pluggable Authentication Modules) is the standard authentication framework for Linux. It provides a way to decouple applications that require authentication (like sshd, sudo, or login) from the actual authentication methods (passwords, 2FA, biometric, etc.).

Without PAM, every program would need to implement its own logic to read /etc/shadow, query an LDAP server, or check a fingerprint reader. This would be a security nightmare. PAM acts as a middleman: the application asks “Can this user come in?”, and PAM executes a pre-configured “stack” of modules to find the answer.

The default rules are generally the most permissive, just enough to make a system functional, not secure.

The Four Module Interfaces (module_interface)

Every rule in a PAM configuration file belongs to one of these four categories:

1. auth: Verifies the user’s identity (e.g., “Is this password correct?”).
2. account: Checks if the user is allowed to log in right now (e.g., “Is the account expired?” or “Is it after business hours?”).
3. password: Handles updating the authentication token (e.g., enforcing password complexity during a change).
4. session: Manages what happens before and after the user is logged in (e.g., mounting a home directory or setting environment variables).

PAM Configuration Syntax

module_interface    control_flag    module_path    module_arguments

Control Flags

• required: The module must succeed. If it fails, the user is ultimately denied, but PAM continues to run other modules in the stack so the user can’t guess which part failed.
• requisite: The module must succeed. If it fails, the authentication fails immediately and the stack stops.
• sufficient: If this module succeeds and no previous required modules have failed, the authentication is granted immediately, skipping the rest of the stack.
• optional: Success or failure is ignored unless this is the only module in the stack.
• **include / substack**: Pulls in rules from another file (e.g., common-auth or system-auth).

Distribution-Specific Implementation

While the syntax is universal, how distributions organize their files in /etc/pam.d/ varies significantly.

Note on FreeBSD

FreeBSD uses OpenPAM instead of Linux-PAM. The configuration is nearly identical, but module paths are usually in /usr/lib/ and you often don’t need to specify the .so extension in the config files.

Best Practices for Production

• Use pam_faillock: Protect against brute-force attacks by locking accounts after $N$ failed attempts.
• Enforce pam_pwquality: Require a minimum length and complexity for new passwords.
• Least Privilege: Use pam_wheel to restrict su access only to members of the administrative group.
• Local Backdoor: Ensure local accounts (like a rescue admin) can still log in if external services (LDAP/AD/2FA) are down by placing pam_unix.so correctly in the stack.

References

• Arch Wiki: PAM
• Debian: Chapter 4 - Authentication
• Gentoo Wiki: PAM
• Red Hat: System-Level Authentication Guide
• NIST SP 800-63B: Digital Identity Guidelines
• CIS Benchmarks (Security Hardening)