Introduction to PAMby Jennifer Vesperman
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.
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.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_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
pam_warn.so in the
other configuration file will identify programs which expect, but don't have, PAM configurations.
In each file in
/etc/pam.d, the configuration lines are:
module-type control-flag module-path arguments
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.
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:
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
requiredmodule has failed, no other modules of this module type are invoked. (This overrides the
requiredexecution 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.
The path name of the module.
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
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
use_first_pass-- Don't prompt the user for a password, instead use the results of the preceding
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