PAM - Pluggable Authentication Modules

Pluggable Authentication Modules — to achieve its pluggable, modular design, PAM adopts a layered design philosophy: it decouples each module from the application, then uses the PAM API as the link between the two, letting users easily plug new authentication modules into an application, or replace existing components, without needing to modify the application at all. This lets an application flexibly plug in whichever functional modules it needs. [1]

Configuration

/etc/pam.conf/*

The configuration file also lives at the application interface layer, and works together with the PAM API to achieve the goal of flexibly plugging in whatever authentication modules an application needs. Its role is mainly to select the specific authentication modules for an application, combine modules together, and define module behavior. The configuration file consists of configuration entries (one per line), and each line is split into four columns: the first column is the PAM interface type, the second is the PAM control type, the third is the PAM module, and the fourth is the parameters passed to the PAM module [2]

Interface types

Specifies which PAM authentication interface type a program uses. Not all four of these interface types are required by every application — they’re selected as needed.

• auth — the authentication-type interface, used to check the user and password and assign permissions; this type of module provides two kinds of service for user verification: prompting the application to have the user enter a password or other token to confirm the user’s legitimacy, and granting permissions, setting group membership, or other privileges based on the user’s credentials.

• account — the account-type interface, mainly responsible for checking account legitimacy, confirming whether an account has expired, whether it’s permitted to log into the system, etc.; this type of module performs non-authentication-based account management. It’s mainly used to restrict/allow the time window during which a user can access a given service, the currently available system resources (the maximum number of users), and restrict where a user can log in from (e.g. root can only log in via the console). In most cases, auth and account are used together to restrict user login and service usage, giving more complete restrictions.

• password — the password-type interface. Controls the entire process of a user changing their password — what some documentation calls upgrading the user’s authentication token.

• session — the session-type interface, implementing session control from successful user login through to logout; it handles things that need to be done before/after providing service to the user. This includes: opening/closing information exchange, monitoring directories, setting up the user’s session environment, and so on. In other words, this is the final gate before the system formally provides service.

Control types

Specifies how to handle the result of a PAM module’s authentication — in short, what happens after authentication succeeds or fails, and how that’s controlled.

• required — indicates that this line’s module succeeding is a necessary condition for the user to pass authentication. Only once all modules marked required have all succeeded can the program pass authentication. Also, if any module marked required produces an error, PAM does not immediately return the error message to the application — instead it returns the error message to the calling program only after all modules have been invoked. The purpose of this is to keep the user from knowing which module rejected them, protecting the system service in a concealed way.

• requisite — similar to required: only once a module marked with this flag returns success can the user pass authentication. The difference is that as soon as it fails, no further modules later in the stack are executed, the authentication process ends right there, and an error message is returned immediately.

• optional — indicates that even if the module on this line fails verification, the user can still pass authentication. Within PAM, after a module marked with this flag fails, processing continues to the next module. In other words, even if the module specified on this line fails verification, the user is still allowed to use the service the application provides. With this flag, the PAM framework ignores the verification error produced by this module and continues on to the next module in the stack.

• sufficient — indicates that this line’s module succeeding is a sufficient condition for the user to pass authentication. In other words, as soon as a module marked sufficient succeeds, PAM immediately returns a success result to the application without trying any further modules — even if later modules in the stack use the requisite or required control flag. When a module marked sufficient fails, it’s treated as if it were optional. So a configuration entry with the sufficient flag does not, on its own, cause the overall verification to fail when it errors out, but the moment it succeeds the gate swings wide open. So this control flag must be used with great care.

• include — indicates that other PAM configuration files are invoked during the verification process. On RHEL systems, quite a lot of applications achieve authentication by fully invoking /etc/pam.d/system-auth, rather than having to write out configuration entries one by one again. This also means that, in many cases, as long as a user can log into the system, most applications can pass authentication as well.

Module path

i368/i686：/lib/security/
x86_64：/lib64/security

pam_access.so implements comprehensive access control based on hostname (either a plain hostname or an FQDN), IP address, and user. [3]

pam_tally.so monitors the number of a user’s unsuccessful login attempts, and once the module’s configured limit is reached, locks the user out for a period of time to prevent brute-force attacks by hacking tools. [4]

pam_env.so sets and changes environment variables after a user logs in

pam_unix.so prompts the user for a password, and compares the user’s password against the password information recorded in /etc/shadow

pam_succeed_if.so places some restrictions on a user’s login conditions

pam_deny.so is a special module whose return value is always “no”; similar to the configuration convention used by most security mechanisms, after all authentication rules have run, it directly rejects any request that doesn’t match any rule.

pam_keyinit.so establishes a keyring for a user when they log in, and revokes it when they log out

pam_limits.so restricts a user’s usage of various system resources during a session

pam_rootok.so lets a user with uid 0 — i.e. root — pass authentication directly without entering a password.

Module arguments

Passes arguments to a module, such as a URL or a timeout value

References

[1]

Basic Concepts and Architecture of Linux Pluggable Authentication Modules

[2]

Linux Pluggable Authentication Modules (PAM): Configuration File, How It Works, and Flow

[3]

Common Linux Pluggable Authentication Module (PAM) Application Examples (Part 1)

[4]

Common Linux Pluggable Authentication Module (PAM) Application Examples (Part 2)