PAM


PAM

PAM (actually Linux-PAM, or Linux Pluggable Authentication Modules) allows a system administrator to determine how applications use (page ) to verify the identity of a user. PAM provides shared libraries (page ) of modules (located in /lib/security) that, when called by an application, authenticate a user. The term "Pluggable" in PAM's name refers to the ease with which you can add and remove modules from the authentication stack. The configuration files kept in the /etc/pam.d directory determine the method of authentication and contain a list, or stack, of calls to the modules. PAM may also use other files, such as /etc/passwd, when necessary.

Instead of building the authentication code into each application, PAM provides shared libraries that keep the authentication code separate from the application code. The techniques of authenticating users stay the same from application to application. PAM enables a system administrator to change the authentication mechanism for a given application without ever touching the application.

PAM provides authentication for a variety of system-entry services (login, ftp, and so on). You can take advantage of PAM's ability to stack authentication modules to integrate system-entry services with different authentication mechanisms, such as RSA, DCE, Kerberos, and smartcards.

From login through using su to shutting the system down, whenever you are asked for a password (or not asked for a password because the system trusts that you are who you say you are), PAM makes it possible for system administrators to configure the authentication process. It also makes the configuration process essentially the same for all applications that use PAM for authentication.

The configuration files stored in /etc/pam.d describe the authentication procedure for each application. These files usually have names that are the same as or similar to the name of the application that they authenticate for. For example, authentication for the login utility is configured in /etc/pam.d/login. The name of the file is the name of the PAM service that the file configures. Occasionally one file may serve two programs. PAM accepts only lowercase letters in the names of files in the /etc/pam.d directory.

There is no relationship between PAM services and the /etc/services file. The name of the PAM service is an arbitrary string that each application gives to PAM; PAM then looks up the configuration file with that name and uses it to control authentication. There is no central registry of PAM service names.

Caution: Do not lock yourself out of the system

Editing PAM configuration files correctly takes care and attention. It is all too easy to lock yourself out of the computer with a single mistake. To avoid this problem, always keep backup copies of the PAM configuration files you edit, test every change thoroughly, and make sure you can still log in once the change is installed. Keep a Superuser session open until you have finished testing. When a change fails and you cannot log in, use the Superuser session to replace the newly edited files with their backup copies.

PAM warns you about errors it encounters, logging them to the /var/log/messages or /var/log/secure files. Review these files if you are trying to figure out why a changed PAM file is not working properly. To prevent a malicious user from seeing information about PAM unnecessarily, PAM sends error messages to a file rather than to the screen.

More Information

Local

/usr/share/doc/pam-*/html/index.html

Web

Linux-PAM System Administrators' Guide

HOWTO

User Authentication HOWTO

Configuration Files, Module Types, and Control Flags

Following is an example of a PAM configuration file. Comment lines begin with a pound sign (#).

Login module 

$ cat /etc/pam.d/login
%PAM-1.0auth       required     pam_securetty.so
auth       include       system-auth
account    required      pam_nologin.so
account    include       system-auth
password   include       system-auth
pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
session    include       system-auth
session    required     pam_loginuid.so
session    optional      pam_console.so
pam_selinux.so open should be the last session rule
session    required     pam_selinux.so open

The first line is a special comment; it will become significant only if another PAM format is released. Do not use #% other than in the first line of the preceding example.

The rest of the lines tell PAM to do something as part of the authentication process. Lines that begin with # are comments. The first word on each line is a module type indicator: account, auth, password, or session (). The second is a control flag (), which indicates the action PAM should take if authentication fails. The rest of the line contains the name of a PAM module (located in /lib/security) and any arguments for that module. The PAM library itself uses the /etc/pam.d files to determine which modules to delegate work to.

Table 11-5. Module type indicators

Module type

Description

Controls

account

Account management

Determining whether an already authenticated user is allowed to use the service she is trying to use. (That is, has the account expired? Is the user allowed to use this service at this time of day?)

auth

Authentication

Proving that the user is authorized to use the service. This may be done using passwords or another mechanism.

password

Password modification

Updating authentication mechanisms such as user passwords.

session

Session management

Setting things up when the service is started (as when the user logs in) and breaking them down when the service is terminated (as when the user logs out).


You can use one of the control flag keywords listed in to set the control flags.

Table 11-6. Control flag keywords

Keyword

Flag function

required

Success is required for authentication to succeed. Control and a failure result are returned after all modules in the stack have been executed. The technique of delaying the report to the calling program until all modules have been executed may keep attackers from knowing what caused their authentication attempts to fail and tell them less about the system, making it more difficult for them to break in.

requisite

Success is required for authentication to succeed. Further module processing is aborted, and control is returned immediately after a module fails. This technique may expose information about the system to an attacker. However, if it prevents a user from giving a password over an insecure connection, it might keep information out of the hands of an attacker.

sufficient

Success indicates that this module type has succeeded, and no subsequent required modules of this type are executed. Failure is not fatal to the stack of this module type. This technique is generally used when one form of authentication or another is good enough: If one fails, PAM tries the other. For example, when you use rsh to connect to another computer, pam_rhosts first checks whether your connection can be trusted without a password. If the connection can be trusted, the pam_rhosts module reports success, and PAM immediately reports success to the rsh daemon that called it. You will not be asked for a password. If your connection is not considered trustworthy, PAM starts the authentication over, asking for a password. If this second authentication succeeds, PAM ignores the fact that the pam_rhosts module reported failure. If both modules fail, you will not be able to log in.

optional

Result is generally ignored. An optional module is relevant only when it is the only module on the stack for a particular service.


PAM uses each of the module types as requested by the application. That is, the application will ask PAM separately to authenticate, check account status, manage sessions, and change the password. PAM will use one or more modules from the /lib/security directory to accomplish each of these tasks.

The configuration files in /etc/pam.d list the set of modules to be used for each application to perform each task. Each such set of the same module types is called a stack. PAM calls the modules one at a time in order, from the top of the stack (the first module listed in the configuration file) to the bottom. Each module reports success or failure back to PAM. When all stacks of modules (with some exceptions) within a configuration file have been called, the PAM library reports success or failure back to the application.

Example

Part of the login service's authentication stack follows: 

$ cat /etc/pam.d/login
#%PAM-1.0
auth       required     pam_securetty.so
auth       include      system-auth
account    required     pam_nologin.so
...

The login utility first asks for a username and then asks PAM to run this stack to authenticate the user. Refer to and on page .

  1. PAM first calls the pam_securetty (secure tty) module to make sure that the root user logs in only from an allowed terminal (by default, root is not allowed to run login over the network; this policy helps prevent security breaches). The pam_securetty module is required to succeed if the authentication stack is to succeed. The pam_securetty module reports failure only if someone is trying to log in as root from an unauthorized terminal. Otherwise (if the username being authenticated is not root or if the username is root and the login attempt is being made from a secure terminal), the pam_securetty module reports success.

    Success and failure within PAM are opaque concepts that apply only to PAM. They do not equate to true and false as used elsewhere in the operating system.

  2. The system-auth module checks that the user who is logging in is authorized to do so, including verification of the username and password.

  3. The pam_nologin module makes sure that if the /etc/nologin.txt file exists, only the root user is allowed to log in. (That is, the pam_nologin module reports success only if /etc/nologin.txt does not exist or if the root user is logging in.) Thus, when a shutdown has been scheduled for some time in the near future, the system administrator can keep users from logging in on the system only to experience a shutdown moments later.

The account module type works like the auth module type but is called after the user has been authenticated; it acts as an additional security check or requirement for a user to gain access to the system. For example, account modules might enforce a policy that a user can log in only during business hours.

The module type sets up and tears down the session (perhaps mounting and unmounting the user's home directory). One common session module on a CentOS Linux system is the pam_console module, which sets the system up especially for users who log in at the physical console, rather than remotely. A local user is able to access the floppy and CD drives, the sound card, and sometimes other devices as defined by the system administrator.

The module type is a bit unusual: All modules in the stack are called once; they are told to get all information they need to store the password to persistent memory, such as a disk, but not actually to store it. If it determines that it cannot or should not store the password, a module reports failure. If all password modules in the stack report success, they are called a second time and told to store to persistent memory the password they obtained on the first pass. The password module is responsible for updating the authentication information (that is, changing the user's password).

Any one module can act as more than one module type; many modules can act as all four module types.

Modifying the PAM Configuration

Some UNIX systems require that a user be a member of the wheel group to use the su command. Although CentOS Linux is not configured this way by default, PAM allows you to change the default by editing the /etc/pam.d/su file: 

$ cat /etc/pam.d/su
#%PAM-1.0
auth            sufficient      pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth           sufficient      pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
#auth           required        pam_wheel.so use_uid
auth            include          system-auth
account         include          system-auth
password        include          system-auth
session         include          system-auth
session         optional        pam_xauth.so

The third through sixth lines of the su module contain comments that include the lines necessary to permit members of the wheel group to run su without supplying a password (sufficient) and to permit only users who are in the wheel group to use su (required). Uncomment one of these lines when you want the system to follow one of these rules.

Caution: Brackets ([]) in the control flags field

You can set the control flags in a more complex way than described in this section. When you see brackets ([]) in the control flags position in a PAM configuration file, the newer, more complex method is in use. Each comma-delimited argument is a value=action pair. When the result returned by the function matches value, action is evaluated. For more information refer to the PAM System Administrator's Guide (/usr/share/doc/pam-*/txts/pam.txt).

Caution: Do not create /etc/pam.conf

You may have encountered PAM on other systems where all configuration is arranged in a single file (/etc/pam.conf). This file does not exist on CentOS Linux systems. Instead, the /etc/pam.d directory contains individual configuration files, one per application that uses PAM. This setup makes it easy to install and uninstall applications that use PAM because you do not have to modify the /etc/pam.conf file each time. If you create a /etc/pam.conf file on a system that does not use this file, the PAM configuration may become confused. Do not use PAM documentation from a different system. Also, the requisite control flag is not available on some systems that support PAM.