Open Source

Using Pluggable Authentication Modules with Linux

PAM is used to protect Linux and UNIX systems from compromise through authentication, logging, and session management. Learn more about PAM, its configuration, and some of the modules available for it in this Daily Feature.


Pluggable Authentication Modules (PAM) is used to protect Linux and UNIX systems from compromise through the process of authentication, logging, and session management. In this Daily Feature article, I will discuss the Red Hat Linux version of PAM, its configuration, and some of the modules available for it.

PAM overview
Any installation of PAM relies on three main components to provide authentication services:
  • PAM-aware applications—Such as login, passwd, ftp, etc.
  • PAM libraries—Located in /lib/security, used to load PAM modules
  • PAM configuration files—Usually either a single /etc/pam.conf file, or a group of access-control files located in the /etc/pam.d directory

PAM execution involves the following steps (illustrated in Figure A):
  1. An application invokes (executes) PAM.
  2. PAM reads the configuration file for the application to determine which modules are required to provide authentication.
  3. PAM loads the required modules (in the order specified) in the configuration file.
  4. PAM may be required to prompt the user for more information through the application using PAM. A prompt for a password would be a typical request in this situation.
  5. If the user satisfies the prompt, access is granted, and PAM waits for the next service request.
  6. If the user does not satisfy the prompt, access is denied, and an error message is displayed. As a security feature, this message will not usually inform the user why access is denied.

Figure A
The PAM authentication process.


PAM may be configured using either a single /etc/pam.conf file, or using a /etc/pam.d directory, with a separate configuration file for each PAM-aware application. The names of the files in this directory will match the names of the applications to which they apply. There are several advantages to using the /etc/pam.d directory approach, including:
  • It’s easier to configure access to applications.
  • There is a single file associated with each PAM-aware application. This means access to one application may be changed without affecting other applications.
  • Symbolic links may be used to link several configuration files together. This allows the administrator to provide consistent access for a broad range of applications.
  • Each service uses its own configuration file so that when a user requires a service, access to that service is easier.
  • Each new application installed may have its own configuration file in /etc/pam.d.
  • Linux filesystem security allows for easy protection of all files in /etc/pam.d.
This article will assume the use of /etc/pam.d.
The /etc/pam.d directory
The /etc/pam.d directory lists the files that are used to control access to PAM-aware applications. Table A shows a typical listing for the /etc/pam.d directory.

Table A
Chfn poweroff mcserv reboot shutdown
Chsh gnorpm-auth other rexec su
Gdm linuxconf passwd rlogin vlock
Halt linuxconf-pair pop rsh xdm
Imap kde login    

Each of the configuration files in the /etc/pam.d directory uses the following form:
  • module-type
  • control-flag
  • module-path
  • arguments

Module-type
The module-type determines the behavior of a module. The same PAM may be used several times within a PAM configuration, and may be defined as a different type of module each time. There are four types of modules used by PAM:
  • auth
  • account
  • session
  • password

Table B lists the four module-types used with PAM configuration files.

Table B
Module-type Function
auth Forces an application to prompt for user identification
account Checks user account characteristics, such as password aging, login time restrictions, and remote login restrictions
session Used to setup the user environment, and session logging
password Used to update the user authentication indicator, normally a password

Control-flag
How the PAM library reacts to the success or failure of its associated module is determined by the control-flag. When modules are stacked, they execute one after another, in succession. A control-flag indicates the importance of an individual module within the stack and may have the following functions:
  • required—The required module specifies which modules must be executed successfully before access is granted. When used in a module stack, all other modules are executed. If access is denied, the user will not know which module or modules failed.
  • requisite—A requisite module must execute successfully, or all other modules in a stack will fail to execute.
  • optional—An optional module is not required for access to a service to be granted. If this is the only module used, unsuccessful execution may cause an application to fail.
  • sufficient—If a sufficient module executes successfully, no other modules in the stack are executed, and access to the application is granted.

Arguments
Arguments are used to pass options to a module. All arguments are optional.

The arguments used with PAM include:
  • use_first_pass—The use_first_pass argument specifies that the previously entered password is to be used. If this argument is unsuccessful, PAM will prompt the user for another password. Used with the password and auth modules only.
  • try_first_pass—If the user's password fails, PAM will issue a prompt for another password. This argument is used with the auth and password modules only.
  • debug—provides output to the syslog facility. The action specified by this control-flag depends upon the module used with it.
  • no_warn—When this is used, warning messages are not passed to applications.
  • nullock—Allows user accounts with no passwords to be used. This option should never be used. The default for the auth module-type is to assume any account with no password is a locked account.
  • nodelay—Forces auth module-type to return immediately on failure. The auth module-type will normally delay on failure, making an intruder use more time to guess passwords.
  • module-path—The module-path is used to specify the absolute pathname of a specific PAM module. This path will normally be /lib/security for all PAM modules.

Module stacking
Module stacking refers to the practice of using more than one module for a specific application. Control-flags are used to determine the priority of each module in a given stack.

Each file in /etc/pam.d contains a series of entries, and each of these entries uses a module-type, control-flag, and module-path. Some characteristics of module stacks are listed below:
  • If the modules in any one of these files are all the same type, they are referred to as a module stack.
  • Modules will be executed in the order in which they are entered in the file, unless a control-flag is used to terminate the execution of a module appearing later in the stack.
  • The entire stack is used to control access for a specific service or application.
  • Arguments may be used to control the actions of a module.

PAM libraries
PAM libraries are the actual modules used to authenticate users. The same module may be used for different purposes within the same configuration file, depending on the module-type, and the keyword specified. The PAM libraries will read one or more configuration files, and will then grant or deny access to a user, depending on the criteria the library uses. The two directories where PAM libraries are located are:
  • /lib/security
  • /usr/lib/security

Frequently used PAM libraries include:
  • pam_access—Reads the /etc/security.conf file to determine whether the user or host will be allowed or denied access.
  • pam_cracklib—Used to check new password choices in the crack library. Crack is a common password-guessing utility.
  • pam_limits—Reads the /etc/security/limits.conf file to allow or deny user access based on available system resources.
  • pam_wheel—Used to restrict root access to users who are members of the group wheel.
The above list of PAM modules is used for illustration only. The complete list is comprised of approximately 40 modules. In an upcoming Daily Feature article, I will cover more detailed information on PAM modules and how they are best employed.
Getting ready for PAM
Any time security measures are employed on a system, the user’s ability to use at least some of the system's capabilities will be denied. This is true for any security package, whether you are configuring PAM, or a firewall for a multiserver network. Prior to configuring PAM, the system administrator should perform the actions listed below:
  • Always copy the existing /etc/pam.d configuration files before making any changes. If PAM is configured incorrectly, it is possible to deny all users, including root and system access.
  • Ensure that the permissions on the /etc/pam.d directory are set to read-write-execute for root only. Configure all configuration in /etc/pam.d to read-write by root only. No other users need to see the contents of this directory. These steps are accomplished with the following commands:
chmod u=rwx /etc/pam.d
cd /etc/pam.d
chmod u=rw *

  • Try the new PAM configuration on a test server first. This will allow you to eliminate configuration problems prior to employing on a production server.
  • Linux and PAM modules are publicly available software. Ensure you obtain any PAM-related modules from a trusted source.

Conclusion
This article provided a brief description of Pluggable Authentication Modules (PAM). In it, I discussed the configuration options available with PAM and the advantages to using the /etc/pam.d directory method. I also explained the modules employed by PAM and how to make entries in the configuration files used by PAM modules.

Jim McIntyre, retired from the Canadian navy, has a total of 12 years of IT training and experience, as well as extensive technical support experience. Jim completed the Novell CNE program, the Adult Education program at Saint Francis Xavier University, and the Webmaster Program at Dalhousie University. His hobbies include golf and hiking.

The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

Editor's Picks

Free Newsletters, In your Inbox