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.
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 FlagsFollowing 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.
You can use one of the control flag keywords listed in Table 11-6 to set the control flags.
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. ExamplePart 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.
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 ConfigurationMac 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. |