PAM (actually Linux-PAM, or Linux Pluggable Authentication Modules) allows a system administrator to determine how applications use authentication (page 1020) to verify the identity of a user. PAM provides shared libraries (page 840) 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[3] 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.
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 www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html
HOWTO User Authentication HOWTO 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 %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 (Table 11-5). The second is a control flag (Table 11-6), 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.
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, 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. ExamplePart 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 Table 11-5 and Table 11-6 on page 440.
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 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 Red Hat 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 password 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 ConfigurationSome UNIX systems require that a user be a member of the wheel group to use the su command. Although Red Hat 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 Red Hat 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. |