Next: Example configuration file entries Up: Linux Authentication Systems Previous: How User Information is

PAM Pluggable Authentication Modules

Traditionally user authentication is programmed directly into applications. With this method user each developer has to write his own authentication functions. Using PAM (Pluggable Authentication Modules), applications can be developed with a PAM interface, and the system administrator can choose any number of PAM modules to do authentication and other tasks. This seperates user authentication from the application, and allows ``plugging in'' of different authentication methods, without the need to rewrite the application.

PAM is built into many Linux distributions, including Caldera 1.3, 2.2 and later; Debian 2.2 and later; Turbo Linux 3.6 and later; Red Hat 5.0 and later; and SuSE 6.2 (partial support). FreeBSD supports PAM from version 3.1.

PAM (Pluggable Authentication Modules) is a suite of shared libraries that enable the local system administrator to choose how applications authenticate users.

The function of the configuration file(s) is to provide a mapping from the application's service name to a selection of modules that provide authentication services to the raw application. When a pam aware application with a file in /etc/pam.d starts, the PAM library loads the configuration for the specified service and constructs four module chains (one for each facility.) If the configuration does not specify any modules for one or more facilities, the configuration for the ``other'' service is used instead for these facilities.

Linux as a server, can provide several different services (e.g., web, ftp with areas restricted by password control). Through the use of modules, PAM can enable a program to search through several different password databases, even if that program is not explicitly coded for that particular database.

Here are some examples of the possibilities that this enables.

• Apache has a module that provides PAM services. Now authentication to use particular directories can be conducted by PAM, which means that the range of modules that are available to PAM can be used, including RADIUS, NIS, NCP (which means that Novell password databases can be used).
• pppd has a PAMified version (available from RedHat) Now it is possible to use a series of databases to authenticate ppp users. In addition to the normal Linux-based password databases (such as /etc/passwd and /etc/shadow), you can use PAM modules to authenticate against Novell password databases or NT-based password databases.
• The preceding two examples can be combined. Imagaine that the persons in your office/department are already registered with a username and password in a Novell or NT LAN. If you wanted to use this database on your Linux server (for PPP access, for web access, or even for normal shell access), you can use PAM to authenticate against this existing database, rather than maintain a separate database on both Linux and the LAN server.

PAM configuration files, located in /etc/pam.d and named for the service which they control have three fields, with optional fourth and greater fields. The first field in the configuration file is the module-type indicatiing which of four PAM management services the correspoding module will provide to the application. PAM deals with four separate types of management services. The type token tells PAM what type of authentication is to be used for this module. Modules of the same type can be "stacked", requiring a user to meet multiple requirements to be authenticated. The four types of management services are: authentication management; account management; session management; and password management.

account

Determines whether the user is allowed to access the service. This is different from establishing whether the user is who they say they are. Account management deals with enforcing the expiration of passwords and preventing logins during system time.

auth

Determines whether the user is who they claim to be, usually by a password, but perhaps by a more sophistcated means, such as biometrics.

password

Provides a mechanism for the user to change their authentication. Again, this usually their password.

session

Things that should be done before and/or after the user is authenticed. This might included things such as mounting/unmounting the user home directory, logging their login/logout, and restricting/unrestricting the services available to the user. 

Control:

 

PAM modules can be stacked - there can be any number of modules of the same module type for a single application. The application is not told of the individual success or failure of any module, only of the success or failure of the stack. The control flags determine how each module affects the success or failure of the stack. Modules in the stack are executed in the order they are listed in the configuration file.

The second field in the configuration file is the control token, which tells PAM what should be done in if authentication by this module fails. PAM recognizes four control types: required, requisite, sufficient, and optional.

• required - The module must succeed for the stack of this module type to succeed. Failure to authenticate via this module results in immediate denial of authentication.
• requisite - The module must succeed for the stack of this module type to succeed. Failure also results in denial of authentication, although PAM will still call all the other modules listed for this service before denying authentication.
• sufficient - Success of this module is sufficient for the stack of this module type to succeed. If authentication by this module is successful, PAM will grant authentication, even if a previous required module failed.
• optional - Not critical to the success or failure of the stack. If at least one non-optional module succeeds or fails, the result of this module is ignored when calculating the success or failure of the stack. Whether this module succeeds or fails is only significant if it is the only module of its type for this service.

Module Path:

 

The module-path tells PAM which module to use and (optionally) where to find it. Most configurations only contain the module's name. Since Linux-PAM-0.56 was released there is support for a default authentication-module directory, and a full path is no longer required, only the name of the module. PAM looks for the modules in the default PAM module directory, normally /usr/lib/security. However, if your linux distribution conforms to the Linux Filesystem standard, PAM modules can be found in /lib/security.

Module Arguments:

 

The fourth and greater fields contain any arguments to the module. Each module has its own arguments. For example, in our login configuration, the "nulok" ("null ok", argument being passed to pam_unix.so module, indicating the a blank ("null") password is acceptable ("ok").

The following are a list of module options that are likely to be recognize by all modules:

debug

 

Use the syslog(3) call to log debugging information to the system log files.

no_warn

 

Instruct module to not give warning messages to the application.

use_first_pass

 

The module should not prompt the user for a password. Instead, it should obtain the previously typed password (from the preceding auth module), and use that. If that doesn't work, then the user will not be authenticated. (This option is intended for auth and password modules only).

try_first_pass

 

The module should attempt authentication with the previously typed password (from the preceding auth module). If that doesn't work, then the user is prompted for a password. (This option is intended for auth modules only).

use_mapped_pass

 

This argument is not currently supported by any of the modules in the Linux-PAM distribution because of possible consequences associated with U.S. encryption exporting restrictions. Within the U.S., module developers are, of course, free to implement it (as are developers in other countries). For compatibility reasons we describe its use as suggested in the DCE-RFC 86.0, see section bibliography for a pointer to this document.

The use_mapped_pass argument instructs the module to take the clear text authentication token entered by a previous module (that requests such a token) and use it to generate an encryption/decryption key with which to safely store/retrieve the authentication token required for this module. In this way the user can enter a single authentication token and be quietly authenticated by a number of stacked modules. Obviously a convenient feature that necessarily requires some reliably strong encryption to make it secure. This argument is intended for the auth and password module types only.

expose_account

 

In general the leakage of some information about user accounts is not a secure policy for modules to adopt. Sometimes information such as users names or home directories, or preferred shell, can be used to attack a user's account. In some circumstances, however, this sort of information is not deemed a threat: displaying a user's full name when asking them for a password in a secured environment could also be called being 'friendly'. The expose_account argument is a standard module argument to encourage a module to be less discrete about account information as it is deemed appropriate by the local administrator.

---

Subsections

• • • Example configuration file entries
    • Basic PAM modules

---

Next: Example configuration file entries Up: Linux Authentication Systems Previous: How User Information is
2005-05-04