Introduction to PAM

by Jennifer Vesperman
09/27/2001

User authentication has always been a problem. Build it into a program, and it's hard to change. Leave it out, and you have no security at all. Now there's an alternative: PAM, or Pluggable Authentication Modules.

PAM provides an interface that programs can use to connect to whatever authentication methods are desired. Authentication can be as trivial as the user typing "hello world", as complex as biometrics, or as prosaic as passwords.

PAM isn't the only way to do this. GSS-API, defined in RFCs 1508 and 1509, is a similar authentication interface protocol. Kerberos, SSh, and Heimdal are different, and focus on securing the authentication process itself rather than linking applications to authentication modules.

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.

Configuring PAM

Originally, the PAM configuration file was /etc/pam.conf. More recent versions of PAM use a separate file for each PAM-using program, in the directory /etc/pam.d, though some will check both /etc/pam.conf and /etc/pam.d when attempting to authenticate for a program. /etc/pam.d is recommended -- having separate files for each program prevents misconfigurations for one program from affecting others.

Defaults: The 'other' file

The default case of a PAM configuration is /etc/pam.d/other (or the lines for the other program in /etc/pam.conf). For a secure installation, configure other to use the pam_deny.so and pam_warn.so modules to block access to unconfigured programs. If you want access rather than security, use pam_permit.so instead of pam_deny.so. To write to syslog, use pam_warn.so. Using pam_warn.so in the other configuration file will identify programs which expect, but don't have, PAM configurations.

Configuration lines

In each file in /etc/pam.d, the configuration lines are:

module-type   control-flag   module-path   arguments

Module types:

• account -- Non-authentication account management, such as limiting the maximum number of users or restricting root access.
• auth -- User authentication, group assignment, and other authentication- and permission-related tasks.
• password -- Updating the authentication token.
• session -- Anything the user needs to have done to connect, such as mounting drives or logging connections.

Control flags:

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.

There are two formats for the control flag. The simpler form uses four keywords: required, requisite, sufficient, and optional. The complex form gives a great deal more control to the system administrator, at the cost of requiring the system administrator to determine an action for each of up to 30 return values. This article covers the simple form.

• required -- The module must succeed for the stack of this module type to succeed. If this module fails, all other modules in the stack are executed but the stack is considered to fail.
• requisite -- The module must succeed for the stack of this module type to succeed. No later module of its type is executed: Failure is reported immediately. The return value is that of the first module in the stack to fail.
• sufficient -- Success of this module is sufficient for the stack of this module type to succeed. If no previous required module has failed, no other modules of this module type are invoked. (This overrides the required execution of all other modules.) Failure of this module does not inherently prevent the stack from succeeding.
• 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.

Module Path:

The path name of the module.

Arguments:

PAM seems like an ideal solution for user authentication extensibility, but how does it fare when put to use? Post your comments

Any arguments to the module. This is module-specific, but most modules should recognize the following arguments:

• debug -- Include debugging statements in syslog.
• expose_account -- Pass information about the account to the application. The default behavior is to limit account information. This argument allows the application to display information such as the user's full name.
• no_warn -- Don't send warning messages to the application.
• try_first_pass -- Don't prompt the user for a password, instead test the password entered for the preceding auth module.
• use_first_pass -- Don't prompt the user for a password, instead use the results of the preceding auth module.
• use_mapped_pass -- Take a clear text authentication token provided by a previous module and generate an encryption/decryption key to store the token. This allows a single token to be securely used by a number of modules. Note that implementing this argument risks breaching the U.S. encryption export restrictions. Check the module's documentation before relying on this argument.

Pages: 1, 2

Next Page