48.4. Pluggable Authentication Modules (PAM)
48.4.1. Advantages of PAM
- a common authentication scheme that can be used with a wide variety of applications.
- significant flexibility and control over authentication for both system administrators and application developers.
- a single, fully-documented library which allows developers to write programs without having to create their own authentication schemes.
48.4.2. PAM Configuration Files
/etc/pam.d/directory contains the PAM configuration files for each PAM-aware application. In earlier versions of PAM, the
/etc/pam.conffile was used, but this file is now deprecated and is only used if the
/etc/pam.d/directory does not exist.
220.127.116.11. PAM Service Files
/etc/pam.d/directory. Each file in this directory has the same name as the service to which it controls access.
/etc/pam.d/directory. For example, the
loginprogram defines its service name as
loginand installs the
/etc/pam.d/loginPAM configuration file.
48.4.3. PAM Configuration File Format
<module interface> <control flag> <module name> <module arguments>
18.104.22.168. Module Interface
auth— This module interface authenticates use. For example, it requests and verifies the validity of a password. Modules with this interface can also set credentials, such as group memberships or Kerberos tickets.
account— This module interface verifies that access is allowed. For example, it may check if a user account has expired or if a user is allowed to log in at a particular time of day.
password— This module interface is used for changing user passwords.
session— This module interface configures and manages user sessions. Modules with this interface can also perform additional tasks that are needed to allow access, like mounting a user's home directory and making the user's mailbox available.
pam_unix.soprovides all four module interfaces.
auth required pam_unix.so
22.214.171.124.1. Stacking Module Interfaces
rebootcommand normally uses several stacked modules, as seen in its PAM configuration file:
cat /etc/pam.d/reboot#%PAM-1.0 auth sufficient pam_rootok.so auth required pam_console.so #auth include system-auth account required pam_permit.so
- The first line is a comment and is not processed.
auth sufficient pam_rootok.so— This line uses the
pam_rootok.somodule to check whether the current user is root, by verifying that their UID is 0. If this test succeeds, no other modules are consulted and the command is executed. If this test fails, the next module is consulted.
auth required pam_console.so— This line uses the
pam_console.somodule to attempt to authenticate the user. If this user is already logged in at the console,
pam_console.sochecks whether there is a file in the
/etc/security/console.apps/directory with the same name as the service name (reboot). If such a file exists, authentication succeeds and control is passed to the next module.
#auth include system-auth— This line is commented and is not processed.
account required pam_permit.so— This line uses the
pam_permit.somodule to allow the root user or anyone logged in at the console to reboot the system.
126.96.36.199. Control Flag
required— The module result must be successful for authentication to continue. If the test fails at this point, the user is not notified until the results of all module tests that reference that interface are complete.
requisite— The module result must be successful for authentication to continue. However, if a test fails at this point, the user is notified immediately with a message reflecting the first failed
sufficient— The module result is ignored if it fails. However, if the result of a module flagged
sufficientis successful and no previous modules flagged
requiredhave failed, then no other results are required and the user is authenticated to the service.
optional— The module result is ignored. A module flagged as
optionalonly becomes necessary for successful authentication when no other modules reference the interface.
requiredmodules are called is not critical. Only the
requisitecontrol flags cause order to become important.
pam.dman page, and the PAM documentation, located in the
/usr/share/doc/pam-<version-number>/directory, where <version-number> is the version number for PAM on your system, describe this newer syntax in detail.
188.8.131.52. Module Name
/lib64/security/directory, the directory name is omitted because the application is linked to the appropriate version of
libpam, which can locate the correct version of the module.
184.108.40.206. Module Arguments
pam_userdb.somodule uses information stored in a Berkeley DB file to authenticate the user. Berkeley DB is an open source database system embedded in many applications. The module takes a
dbargument so that Berkeley DB knows which database to use for the requested service.
pam_userdb.soline in a PAM configuration. The <path-to-file> is the full path to the Berkeley DB database file:
auth required pam_userdb.so db=<path-to-file>
48.4.4. Sample PAM Configuration Files
#%PAM-1.0 auth required pam_securetty.so auth required pam_unix.so nullok auth required pam_nologin.so account required pam_unix.so password required pam_cracklib.so retry=3 password required pam_unix.so shadow nullok use_authtok session required pam_unix.so
- The first line is a comment, indicated by the hash mark (
#) at the beginning of the line.
- Lines two through four stack three modules for login authentication.
auth required pam_securetty.so— This module ensures that if the user is trying to log in as root, the tty on which the user is logging in is listed in the
/etc/securettyfile, if that file exists.If the tty is not listed in the file, any attempt to log in as root fails with a
auth required pam_unix.so nullok— This module prompts the user for a password and then checks the password using the information stored in
/etc/passwdand, if it exists,
/etc/shadow.In the authentication phase, the
pam_unix.somodule automatically detects whether the user's password is in the
passwdfile or the
shadowfile. Refer to Section 37.6, “Shadow Passwords” for more information.
auth required pam_nologin.so— This is the final authentication step. It checks whether the
/etc/nologinfile exists. If it exists and the user is not root, authentication fails.
NoteIn this example, all three
authmodules are checked, even if the first
authmodule fails. This prevents the user from knowing at what stage their authentication failed. Such knowledge in the hands of an attacker could allow them to more easily deduce how to crack the system.
account required pam_unix.so— This module performs any necessary account verification. For example, if shadow passwords have been enabled, the account interface of the
pam_unix.somodule checks to see if the account has expired or if the user has not changed the password within the allowed grace period.
password required pam_cracklib.so retry=3— If a password has expired, the password component of the
pam_cracklib.somodule prompts for a new password. It then tests the newly created password to see whether it can easily be determined by a dictionary-based password cracking program.
- The argument
retry=3specifies that if the test fails the first time, the user has two more chances to create a strong password.
password required pam_unix.so shadow nullok use_authtok— This line specifies that if the program changes the user's password, it should use the
passwordinterface of the
pam_unix.somodule to do so.
- The argument
shadowinstructs the module to create shadow passwords when updating a user's password.
- The argument
nullokinstructs the module to allow the user to change their password from a blank password, otherwise a null password is treated as an account lock.
- The final argument on this line,
use_authtok, provides a good example of the importance of order when stacking PAM modules. This argument instructs the module not to prompt the user for a new password. Instead, it accepts any password that was recorded by a previous password module. In this way, all new passwords must pass the
pam_cracklib.sotest for secure passwords before being accepted.
session required pam_unix.so— The final line instructs the session interface of the
pam_unix.somodule to manage the session. This module logs the user name and the service type to
/var/log/secureat the beginning and end of each session. This module can be supplemented by stacking it with other session modules for additional functionality.
48.4.5. Creating PAM Modules
/usr/share/doc/pam-<version-number>/directory, where <version-number> is the version number for PAM on your system.
48.4.6. PAM and Administrative Credential Caching
pam_timestamp.somodule. It is important to understand how this mechanism works, because a user who walks away from a terminal while
pam_timestamp.sois in effect leaves the machine open to manipulation by anyone with physical access to the console.
pam_timestamp.somodule creates a timestamp file. By default, this is created in the
/var/run/sudo/directory. If the timestamp file already exists, graphical administrative programs do not prompt for a password. Instead, the
pam_timestamp.somodule freshens the timestamp file, reserving an extra five minutes of unchallenged administrative access for the user.
/var/run/sudo/<user>file. For the desktop, the relevant file is
unknown:root. If it is present and its timestamp is less than five minutes old, the credentials are valid.
Figure 48.7. The Authentication Icon
220.127.116.11. Removing the Timestamp File
Figure 48.8. Dismiss Authentication Dialog
- If logged in to the system remotely using
ssh, use the
/sbin/pam_timestamp_check -k rootcommand to destroy the timestamp file.
- You need to run the
/sbin/pam_timestamp_check -k rootcommand from the same terminal window from which you launched the privileged application.
- You must be logged in as the user who originally invoked the
pam_timestamp.somodule in order to use the
/sbin/pam_timestamp_check -kcommand. Do not log in as root to use this command.
- If you want to kill the credentials on the desktop (without using theaction on the icon), use the following command:
pam_timestamp_check -k root </dev/null >/dev/null 2>/dev/nullFailure to use this command will only remove the credentials (if any) from the pty where you run the command.
pam_timestamp_checkman page for more information about destroying the timestamp file using
18.104.22.168. Common pam_timestamp Directives
pam_timestamp.somodule accepts several directives. The following are the two most commonly used options:
timestamp_timeout— Specifies the period (in seconds) for which the timestamp file is valid. The default value is 300 (five minutes).
timestampdir— Specifies the directory in which the timestamp file is stored. The default value is
48.4.7. PAM and Device Ownership
22.214.171.124. Device Ownership
pam_console.somodule is called by
loginor the graphical login programs, gdm, kdm, and xdm. If this user is the first user to log in at the physical console — referred to as the console user — the module grants the user ownership of a variety of devices normally owned by root. The console user owns these devices until the last local session for that user ends. After this user has logged out, ownership of the devices reverts back to the root user.
pam_console.soby editing the following files:
50-default.permsfile, you should create a new file (for example,
xx-name.perms) and enter the required modifications. The name of the new default file must begin with a number higher than 50 (for example,
51-default.perms). This will override the defaults in the
<xconsole>directives in the
/etc/security/console.permsto the following values:
<console>=tty[0-9][0-9]* vc/[0-9][0-9]* :0\.[0-9] :0 <xconsole>=:0\.[0-9] :0
<xconsole>directive entirely and change the
<console>directive to the following value:
126.96.36.199. Application Access
pam_console.somodule as a requirement for use.
48.4.8. Additional Resources
188.8.131.52. Installed Documentation
- PAM-related man pages — Several man pages exist for the various applications and configuration files involved with PAM. The following is a list of some of the more important man pages.
- Configuration Files
pam— Good introductory information on PAM, including the structure and purpose of the PAM configuration files.Note that this man page discusses both
/etc/pam.confand individual configuration files in the
/etc/pam.d/directory. By default, Red Hat Enterprise Linux uses the individual configuration files in the
/etc/pam.confeven if it exists.
pam_console— Describes the purpose of the
pam_console.somodule. It also describes the appropriate syntax for an entry within a PAM configuration file.
console.apps— Describes the format and options available in the
/etc/security/console.appsconfiguration file, which defines which applications are accessible by the console user assigned by PAM.
console.perms— Describes the format and options available in the
/etc/security/console.permsconfiguration file, which specifies the console user permissions assigned by PAM.
pam_timestamp— Describes the
/usr/share/doc/pam-<version-number>— Contains a System Administrators' Guide, a Module Writers' Manual, and the Application Developers' Manual, as well as a copy of the PAM standard, DCE-RFC 86.0, where <version-number> is the version number of PAM.
/usr/share/doc/pam-<version-number>/txts/README.pam_timestamp— Contains information about the
pam_timestamp.soPAM module, where <version-number> is the version number of PAM.
184.108.40.206. Useful Websites
- http://www.kernel.org/pub/linux/libs/pam/ — The primary distribution website for the Linux-PAM project, containing information on various PAM modules, a FAQ, and additional PAM documentation.
NoteThe documentation in the above website is for the last released upstream version of PAM and might not be 100% accurate for the PAM version included in Red Hat Enterprise Linux.