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 /etc/pam.d or /etc/pam.conf file.

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?

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:

1. 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.
2. 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).
3. 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:

1. The authentication module is used to authenticate users or set/destroy credentials.
2. The account management modules perform actions related to access, account and credential expiration, password restrictions/rules, etc.
3. The session management module is used for initializing and terminating sessions.
4. 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_access delivers log-daemon-style login access control using login/domain names depending on pre-defined rules in /etc/security/access.conf.
• pam_cracklib checks the passwords against the password rules.
• pam_env sets/unsets environment variables from /etc/security/pam_env_conf.
• pam_debug debugs PAM.
• pam_deny locks out PAM modules.
• pam_echo prints messages.
• pam_exec executes an external command.
• pam_ftp is the module for anonymous access.
• pam_localuser requires the user to be listed in /etc/passwd.
• pam_unix provides traditional password authentication from /etc/passwd.

There are many other modules (pam_userdb, pam_warn, 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.)

Configuring PAM

PAM configuration is generally implemented in the configuration file residing in /etc/pam.d or /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_name specifies the name of the service/application. (The default is OTHER.)
• Module_type specifies module type (auth/account/session/passwd) for the corresponding service in Service_name field.
• Control_flag specifies the stacking behavior of the module. It can take such values as requisite, required, sufficient, and optional.
• Module_path specifies the path name to the library object which implements the module. It is set to /lib/security by default.
• Module_options/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.

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:

1. First, pam_warn.so is called to log information about the attempt in progress.
2. Then pam_deny.so is 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:

1. Include header files for the PAM implementation (for example, pam_appl.h, pam_misc.h).
2. In the main function, initialize the PAM library libpam.so (which loads the modules specified in the configuration file for application) using a unique handle.
3. Attempt authentication for all modules and handle failure scenarios.
4. Check for user credential and account details.
5. Open a new PAM session.
6. Set the environment for the user using credentials.
7. When the user is done, unset the user environment.
8. Close the PAM session.
9. Exit from the library libpam.so with the handle value.
10. EXIT.

In conclusion

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.