Understanding and configuring PAM
The basic Pluggable Authentication Module and how to configure it and write a login app
For Linux users, sharing files securely is a cumbersome task. For example, needing to recall multiple passwords is taxing, and redesigning system access applications (like login, su, password, ftp, etc.) is time-consuming. Adding to the difficulty is the process of authentication, where a system identifies a user and provides deserved access control to that user.
A history of PAM’s usage
PAM is an API that takes care of authenticating a user to a service. Before PAM, applications like login (and rlogin, telnet, rsh) looked for the username in
/etc/passwd, then compared the two and authenticated the user-typed name. All applications used these shared services, although the implementation details and authority to configure them was not shared.
Next, application developers tried coding their own processes. With this came the need to separate the application and security module (a common security module can be shared by applications and can be configured as needed).
The PAM mechanism integrates multiple low-level authentication schemes into a high-level API that allows programs that rely on authentication to be written independently of the underlying authentication scheme. The principal feature of PAM is the dynamic configuration of authentication through either an
PAM can be configured to deny certain programs the right to authenticate users and to warn when certain programs attempt to authenticate. PAM programs make use of PAM modules (authentication modules): They are attached to applications at runtime in order to work.
Figure 1 shows the basic flow of the PAM model.
Figure 1. PAM library parses the config file and loads modules to it
What operating systems support
PAM was first developed by Sun Microsystems in 1995 and is supported by the following operating system versions (and higher):
- RedHat 5.0
- SUSE 6.2
- Debian 2.2
- Mandrake 5.2
- Caldera 1.3
- TurboLinux 3.6
PAM is also supported by recent versions of Solaris™, AIX®, HP-UX, and Mac OS® X. PAM was later standardized as a part of X/Open UNIX® standardization process (in the X/Open single sign-on service (XSSO) architecture).
What kind of PAM can I get?
Though they are not strictly classified, you could say there are three kinds of PAM:
- Linux-PAM: Linux-PAM covers all of the PAM discussed in this article. The main architecture of PAM on any of the Linux platforms is similar to the Linux-PAM version.
- OpenPAM: OpenPAM is another implementation of PAM developed by Dag-Erling Smorgrav at NAI labs as part of DARPA-CHATS research program. Because it is open source, it is mainly used by FreeBSD, NetBSD, and applications (plus Mac OS X).
- Java™ PAM or JPam: PAM is basically a standard authentication module supporting Linux and UNIX. JPam acts as a bridge between the Java part and the usual PAM. JPam enables the use of PAM modules or facilities (like auth, account, passwd, session, etc.) by Java-based applications. It features JAAS and direct APIs and support for most Unix OS and architectures.
Although these are different PAMs, their primary functionality remains the same.
What are PAM modules like?
Installing PAM is a step-by-step process. See Related topics for installation instructions.
PAM modules are classified into module type. Any given module should implement at least one of the four module type functions:
- The authentication module is used to authenticate users or set/destroy credentials.
- The account management modules perform actions related to access, account and credential expiration, password restrictions/rules, etc.
- The session management module is used for initializing and terminating sessions.
- The password management module performs actions related to password change/updates.
PAM provides different functional capabilities, such as single sign-on authentication, access control, and more. The implementation of each are handled by different modules. Here are some of the major modules:
pam_accessdelivers log-daemon-style login access control using login/domain names depending on pre-defined rules in /etc/security/access.conf.
pam_cracklibchecks the passwords against the password rules.
pam_env sets/unsetsenvironment variables from /etc/security/pam_env_conf.
pam_denylocks out PAM modules.
pam_execexecutes an external command.
pam_ftpis the module for anonymous access.
pam_localuserrequires the user to be listed in /etc/passwd.
pam_unixprovides traditional password authentication from
There are many other modules (
pam_xauth), which take a set of values which they return. (Details of these modules can be found in the PAM administration guide in Related topics.)
PAM configuration is generally implemented in the configuration file residing in
/etc/pam.conf (for old versions).
The configuration file structure
For each service that uses PAM, there is a corresponding file in the directory, which contains the rules or instructions for how authentication and account information should be obtained for that service. There is usually one rule per line.
Fields in the PAM configuration files include:
Service_namespecifies the name of the service/application. (The default is OTHER.)
Module_typespecifies module type (
auth/account/session/passwd) for the corresponding service in
Control_flagspecifies the stacking behavior of the module. It can take such values as
Module_pathspecifies the path name to the library object which implements the module. It is set to
module_args(optional fields) specify the options or arguments that can be passed to the services modules.
The modules are invoked in the order in which they are listed in the configuration file, depending on what the
Control_flag for each entry allows. Control_flag values include:
- Required: All required modules in a stack must pass for a successful result. If one or more of the required module fails, all of the required modules in the stack are implemented, but the first error is returned.
- Sufficient: If a module flagged as sufficient succeeds and no previous required or sufficient modules have failed, then all remaining modules in the stack are ignored and success is returned.
- Optional: If none of the modules in the stack are required and no sufficient modules have succeeded, then at least one optional module of the service/application must succeed.
Examples of PAM config files
Table 1 shows some examples of PAM configuration files on various operating systems.
Table 1. A world of PAM configuration files
|System||Found in …||Type||Control_flag||Module|
|zSUSE 64-bit | 32-bit||/etc/pam.conf||auth||required||/lib64/security/pam_unix.so | /lib/security/pam_unix.so|
|zSUSE 64-bit | 32-bit||/etc/pam.conf||account||required||/lib64/security/pam_unix.so | /lib/security/pam_unix.so|
|zSUSE 64-bit | 32-bit||/etc/pam.conf||session||required||/lib64/security/pam_unix.so | /lib/security/pam_unix.so|
The PAM “other” file
The default PAM configuration file
/etc/pam.d is used for all other services that are not explicitly configured and is perhaps the simplest and most robust default file upon which PAM relies. The internals look something like this:
/etc/pam.d/other File auth required pam_warn.so auth required pam_deny.so account required pam_warn.so account required pam_deny.so password required pam_warn.so password required pam_deny.so session required pam_warn.so session required pam_deny.so
This file is very simple. For all module types, the Control_flag is the same:
required. Two modules are called:
pam_warn.sois called to log information about the attempt in progress.
pam_deny.sois called to simply return a failure and prevent any kind of connection or authentication from taking place.
Therefore, any service that uses PAM must be explicitly configured to allow authentication; otherwise, attempts will fail.
Ten steps to designing a simple PAM login app
These 10 steps can help you implement your own PAM application and help you understand the workings of a PAM session:
- Include header files for the PAM implementation (for example, pam_appl.h, pam_misc.h).
- In the
mainfunction, initialize the PAM library libpam.so (which loads the modules specified in the configuration file for application) using a unique handle.
- Attempt authentication for all modules and handle failure scenarios.
- Check for user credential and account details.
- Open a new PAM session.
- Set the environment for the user using credentials.
- When the user is done, unset the user environment.
- Close the PAM session.
- Exit from the library libpam.so with the handle value.
Relying on PAM to help wrangle low-level authentication efforts into a more manageable whole is a sound move to simplifying this security mechanism. In this article, you’ve learned:
- The basic PAM architecture
- How to configure PAM modules
- An outline of a PAM login app as a guide for understanding how they work
Now you can move onto the more advanced topics in using PAM modules—starting with the resources on the right.