Pluggable Authentication Modules PAMs
With the explosion of network-aware Linux applications, authentication has become an important issue. Traditionally, Linux application developers included their own authentication mechanisms in their programs, ranging anywhere from no authentication (e.g., TFTP) to strong Kerberos and S/Key authentication (e.g., telnet). Hard-coding authentication into each application has several drawbacks:
■ The user is forced into a specific mode of authentication.
■ Changing authentication mechanisms involves recompiling the application.
■ Systems administrators must manage heterogeneous authentication mechanisms.
Originally developed by Sun Microsystems, the Pluggable Authentication Modules (PAM) framework allows administrators to control authentication parameters for network applications. Developers simply adhere to the PAM standard and call a set of dynamic libraries that come with PAM. PAM support is now included in all major Linux distributions, and a growing number of network applications are now using PAM for authentication.
There are two parts to the PAM system:
■ A set of dynamically linked shared libraries (modules) that are typically installed in /lib/security or /usr/lib/security
■ A set of configuration files that are typically installed in /etc/pam.d/
The developer of a networked application (for example, login) simply specifies that authentication is needed in the code before the user is granted a shell. You, as the system administrator, have complete control, using the /etc/pam.d/login configuration file, to specify what type of authentication you want your users to undergo before login gives them access to their shell.
The tasks that PAM takes care of fall into four categories or management groups:
■ Authentication management, where PAM establishes whether the user is who they claim to be. This can be achieved using a simple method like standard username/ passwords, using a more complex method such as challenge-response authentication, or using a time-based hardware token card.
■ Account management, where PAM provides verification services based on the account information. This management group concerns itself with questions like
■ Has the user password expired?
■ Does this user belong to the right group to be allowed access to a particular service?
■ Password management, where PAM takes care of any necessary updates to the authentication token associated with the user. Once the user is authenticated, the password management group prompts a user for a new password if the previous has expired.
■ Session management, where PAM does a number of things in preparation for granting the user access to the resources or right before the service is to be withdrawn. Session management tasks include logging events, mounting home directories, etc.
Installing PAM
Although PAM has become a standard package in most Linux distributions, it's always advisable to make sure you have the latest version. To update an existing PAM installation, enter the following commands:
[ramon]$ sudo rpm -U pam-0.72-37.i386.rpm [ramon]$ rpm -q pam pam-0.72-37
The preceding example shows you were running stock Red Hat 7.0, which came with PAM 0.72-26. This system has now been upgraded to version 0.72-37 using the RPM command.
Configuring PAM
PAM consults a configuration file for each type of network service to authenticate. All files are of the type /etc/pam.d/service where service is the name of the network service to authenticate.
NOTE The /etc/pam.d/other file has a special meaning because it is always consulted after the file specific to the service in question.
For example, the file that controls authentication for the ftp program is in /etc/ pam.d/ftp.
Each line in one of these files is of the format:
module-type control-flag module-path arguments Let's take a closer look at each of these four fields:
module-type A PAM module can be of one of four types:
■ password
Each of these module types corresponds to one of the four fundamental PAM management groups described in the previous section.
control-flag Since modules are often stacked and executed in sequence, the control-flag field determines what effect the success or failure of a single module should have on the overall authentication result returned to the application. This field can be one of the following:
■ required: Failure in this module results in overall authentication failure. Execution continues to the remaining modules.
■ requisite: This value means the same as required, but the execution of the module sequence halts if the result is a failure.
■ sufficient: Success in this module is enough to result in an overall authentication success. If no other required modules are in the sequence, execution stops.
■ optional: Success of this module is not necessary for overall success.
module-path This specifies the path name of the dynamically loadable object file itself, for example, /1ib/security/pam_access.so.
arguments This field is a list of command-line arguments passed to the loadable module when it is invoked by PAM. This is an optional field, since many loadable modules do not take any command-line arguments. The following arguments are common to all modules:
■ debug: The debug argument sends debug information to syslog.
■ no_warn: The no_warn argument forces the module to suppress warning messages to the application.
■ use_first_pass: The use_first_pass argument instructs the module not to prompt the user for a password. Instead, the module should use the previously typed password (from the preceding module). If that does not work, the user is not authenticated.
■ try_first_pass: The try_first_pass argument is similar to the use_first_ pass argument, but the user is prompted for a password if the previous one fails.
PAM Examples t=
Let's start by taking a look at the /etc/pam.d/other file, which gets examined by all « =
PAM authentication requests after the more specific configuration file. Consider the Si "is example in Listing 13.20. ¡a 'i=
Listing 13.20 A sample /etc/pam.d/other file "
[ramon]$ sudo more /etc/pam.d/other
auth required /1ib/security/pam_deny.so account required /1ib/security/pam_deny.so password required /1ib/security/pam_deny.so session required /1ib/security/pam_deny.so
The entries in Listing 13.20 ensure that attempts to access a given service are denied when there is not a more specific /etc/pam.d/ file for the service. The pam_deny.so module simply fails any authentication attempt levied against it.
Consider the more complicated example in Listing 13.21. This example illustrates the PAM configuration used to authenticate the sshd service on a Linux host.
Listing 13.21 PAM configuration for the sshd service
[ramon]$ sudo more /etc/pam.d/sshd
auth required system-auth auth required account required system-auth password required system-auth session required system-auth session required session optional
/1ib/security/pam_stack.so service=
/1ib/security/pam_no1ogin.so /1ib/security/pam_stack.so service=
/1ib/security/pam_stack.so service=
/1ib/security/pam_stack.so service=
/1ib/security/pam_1imits.so /1ib/security/pam_conso1e.so
The first module called is pam_stack. This is simply a way to include the stack from another service, in this case, /etc/pam.d/system-auth. This is the equivalent of including an entire header file inside a code listing by using an include directive. The pam_ limits module is used to set limits on the system resources that can be obtained in a user session, such as the maximum number of open files, the maximum number of concurrent processes, etc. Finally, the pam_conso1e module awards the user certain privileges only when they are physically logged onto the system console.
Since the previous example included the system-auth service (using the pam_stack module), let's look at the configuration of that service in the /etc/pam.d/system-auth file, shown in Listing 13.22.
Listing 13.22 PAM configuration for the system-auth service
[ramon]$ sudo more /etc/pam.d/system-auth
auth sufficient /1ib/security/pam_unix.so likeauth nullok $ md5 shadow auth required /1ib/security/pam_deny.so account sufficient /1ib/security/pam_unix.so account required /1ib/security/pam_deny.so password required /lib/security/pam_cracklib.so retry=3
password sufficient /lib/security/pam_unix.so nullok $ use_authtok md5 shadow password required /lib/security/pam_deny.so session required /lib/security/pam_unix.so
This particular file is significant because it is included in from several other files in the /etc/pam.d directory. It includes the following PAM-loadable modules:
pam_unix The pam_unix module verifies the identity of a Linux user and sets their credentials based on their entry in the /etc/passwd and /etc/shadow files (when appropriate). (This module is explained in more detail in Appendix B, "PAM Module Reference.") In the previous example, the pam_unix module is shown with the following optional arguments:
■ nullok: The nullok argument permits the changing of a password from an empty one.
■ md5: The md5 argument performs the encryption with the MD5 function as opposed to the conventional crypt call.
■ use_authtok: The use_authtok argument forces this module to set the new password to the one provided by the previously stacked password module. For example, you may invoke pam_cracklib (a password-strength-checking module) before pam_unix and would like pam_unix to use the password set by pam_ cracklib (see the example at the end of this section).
■ shadow: The shadow argument enables the use of the /etc/shadow file for password authentication. (See Chapter 2, "System Installation and Setup," for an explanation of the advantages of shadow passwords.)
pam_cracklib The pam_cracklib module relies on the cracklib routine to check the strength of a user password. Even if the cracklib routine likes the password, it goes on to perform some additional checks on the password to make sure that the new password is not:
■ a palindrome of the old password
■ the old password with only a change of case
■ too much like the password
■ a rotated version of the old password
■ already used in the past (previously used passwords are kept in the /etc/ security/opasswd file)
The pam_crak1ib module can be invoked with the following arguments:
■ retry=n : This argument specifies the default number of times that this module will request a new password (for strength checking).
■ min1en=m This argument specifies the minimum acceptable size for the new password plus one.
■ difok=n: This argument specifies the number of characters in the new password that must not be present in the old password.
For example, consider the following example from a /etc/pam.d/passwd file: password required pam_crack1ib.so retry=3 min1en=8 difok=3 password required pam_unix.so use_authtok nu11ok md5
This file shows how you can define an authentication policy for the Linux passwd utility by stacking two modules. The pam_crack1ib module prompts the user for a new password (the user has to type it in twice to make sure it is typed correctly) and examines the new password to ensure that it is strong enough. Note that the user has three chances to type in a good password, which must be at least seven characters long and have at least three characters that are not in the old password. The pam_unix module is then invoked, but by using the use_authtok argument, you make sure that the user is not prompted again for the password. Instead, the one that they just entered into pam_crack1ib is used.
Continue reading here: The pamcracklib Module
Was this article helpful?