PAM

PAM (actually Linux-PAM, or Linux Pluggable Authentication Modules) allows a system administrator to determine how various applications use authentication (page 922) to verify the identity of a user. PAM provides shared libraries (page 486) of modules (located in /usr/lib/pam) that, when called by an application, authenticate a user. Pluggable 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 when necessary. Under OS X, the default PAM configuration uses NetInfo.

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 touching the application.

PAM provides authentication for a variety of system-entry services (e.g., login, ftp). 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 smart cards.

From login through the use of su to system shutdown, 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 systems administrators to configure the authentication process and makes the configuration process essentially the same for all applications that use PAM to handle their 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 configure. 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^[1] 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.

^[1] 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 how it does authentication. There is no central registry of PAM service names.

Tip: Do not lock yourself out of the system

Editing PAM configuration files correctly takes care and attention. It is easy to lock yourself out of the computer with a single mistake. To avoid this type of 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 your 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 any errors it encounters, logging them to the /var/log/secure.log file. Look in this file if you are trying to figure out why a changed PAM file is not working properly. To prevent possibly giving unnecessary information to a malicious user, PAM sends error messages to a file rather than to the screen.

For more information on PAM see the Linux-PAM System Administrators' Guide (www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html). Although the URL contains the word "Linux," the documentation also applies to Mac OS X.

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 # login: auth account password session auth        required       pam_nologin.so auth        sufficient     pam_securityserver.so auth        sufficient     pam_unix.so auth        required       pam_deny.so account     required       pam_permit.so password    required       pam_deny.so session     required       pam_uwtmp.so 

The first line is a comment. The rest of the lines tell PAM to do something as part of the authentication process. The first word on each line is a module type indicator: account, auth, password, or session (Table 11-5). The second word is a control flag (Table 11-6) that indicates what type of action to take if authentication fails. The rest of the line contains the pathname of a PAM module 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 by using passwords or another mechanism.
password	Password changes	Updating authentication mechanisms such as user passwords.
session	Session management	Setting things up when the service is started (for example, when the user logs in) and breaking them down when the service is terminated (for example, when the user logs out).

You can use one of the control flag keywords listed in Table 11-6 to set the control flags.

Table 11-6. Control flags

Flag	Action
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. Of course, 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 or another of authentication 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	The 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 the user, check account status, manage sessions, and change the password. PAM will use one or more modules from the /usr/lib/pam 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 set of modules 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. The modules report success or failure back to PAM. When all the stacks of modules (there are 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 # login: auth account password session auth       required       pam_nologin.so auth       sufficient     pam_securityserver.so auth       sufficient     pam_unix.so ... 

The login utility first asks for a username and then asks PAM to run this stack to authenticate the user. Refer to Table 11-5 and Table 11-6.

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

2. The pam_securityserver module checks with the security daemon, securityd. (On Mac OS X 10.3 and earlier, this program was named SecurityServer.) This check normally authenticates a user. Because this check is marked as sufficient, if it succeeds in authenticating the user, PAM is done and skips the next step.

3. If necessary, the pam_unix module checks for local UNIX-style passwords. Normally this check will fail, because Mac OS X does not use the UNIX-style passwd database.

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

The session module type sets up and tears down the session (perhaps mounting and unmounting the user's home directory). One common session module on a Mac OS X system is the pam_uwtmp module, which records user logins in the utmp and wtmp databases.

The password module type is a bit unusual: All modules in the stack are called once and 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. Indeed many modules can act as all four module types.

Caution: Brackets in the control flags field

You can set the control flags in a more complex way than described in the text. 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 return from the function matches value, action is evaluated. Refer to the Linux-PAM System Administrator's Guide for more information.

Modifying the PAM Configuration

Mac OS X systems require that a user be a member of the wheel or admin group to use su. Some users might prefer not to have this restriction. PAM allows you to remove this restriction by editing the /etc/pam.d/su file:

$ cat /etc/pam.d/su # su: auth account session auth       sufficient     pam_rootok.so auth       required       pam_wheel.so use_uid group=admin group=wheel auth       sufficient     pam_securityserver.so auth       sufficient     pam_unix.so auth       required       pam_deny.so account    required       pam_permit.so password   required       pam_netinfo.so session    required       pam_permit.so 

The second line of the su module requires users to pass the checks in pam_wheel.so to become root. Commenting this line out or removing it allows users who are not members of the wheel or admin groups to use su to become root.