Sample PAM Configuration Files

Following is a sample PAM application configuration file:

#%PAM-1.0 auth     required    /lib/security/pam_securetty.so auth     required    /lib/security/pam_unix.so shadow nullok auth     required    /lib/security/pam_nologin.so account  required    /lib/security/pam_unix.so password required    /lib/security/pam_cracklib.so retry=3 password required    /lib/security/pam_unix.so shadow nullok use_authtok session  required   /lib/security/pam_unix.so

The first line is a comment as denoted by the # character — the comment symbol in PAM configuration files. Lines two through four stack three modules for login authentication.

auth          required      /lib/security/pam_securetty.so

This line makes sure that if the user is trying to log in as root, the tty on which they are logging in is listed in the /etc/securetty file, if that file exists.

auth          required      /lib/security/pam_unix.so nullok

This line causes the user to be asked for a password and then checks the password using the information stored in /etc/passwd and, if it exists, /etc/shadow. The pam_unix.so module automatically detects and utilizes shadow passwords, stored in /etc/shadow, to authenticate users. Please refer to Chapter 7 for more information on shadow passwords.

The argument nullok instructs the pam_unix.so module to allow a blank password.

auth          required      /lib/security/pam_nologin.so

This is the final authentication step. It checks to see if the file /etc/nologin exists. If nologin does exist and the user is not root, authentication fails.

Note

In this example, all three auth modules are checked, even if the first auth module fails. This prevents users from knowing at what stage their authentication failed. Such knowledge in the hands of attackers could allow them to more easily deduce how to crack the system.

account       required      /lib/security/pam_unix.so

This line causes any necessary account verification to be done. For example, if shadow passwords have been enabled, the account component of the pam_unix.so module will check to see if the account has expired or if the user has not changed his or her password within the grace period allowed.

password   required   /lib/security/pam_cracklib.so retry=3

If a password has expired, the password component of the pam_cracklib.so module prompts for a new password. It then tests the newly created password to see whether the it can easily be determined by a dictionary-based password-cracking program. If it fails this test the first time, it gives the user two more chances to create a strong password, because of the retry=3 argument.

password   required    /lib/security/pam_unix.so shadow nullok use_authtok

This line specifies that if the program changes the user’s password, it should use the password component of the pam_unix.so module to do so. This will happen only if the auth portion of the pam_unix.so module has determined that the password needs to be changed — for example, if a shadow password has expired.

The argument shadow tells the module to create shadow passwords when updating a user’s password. The argument nullok instructs the module to allow the user to change his or her 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 how one can stack PAM modules. This argument tells the module not to prompt the user for a new password. Instead, it is to accept any password that passes through previous password module. This way all new passwords must pass the pam_cracklib.so test for secure passwords before being accepted.

session required /lib/security/pam_unix.so

The final line specifies that the session component of the pam_unix.so module will manage the session. This module logs the username and the service type to /var/log/messages at the beginning and end of each session. It can be supplemented by stacking it with other session modules if you need more functionality.

The next sample configuration file illustrates auth module stacking for the rlogin program — a program that allows users to log in remotely.

#%PAM-1.0 auth        required         /lib/security/pam_nologin.so auth        required         /lib/security/pam_securetty.so auth        required         /lib/security/pam_env.so auth        sufficient       /lib/security/pam_rhosts_auth.so auth        required         /lib/security/pam_stack.so service=system-auth

First, pam_nologin.so checks to see if /etc/nologin exists. If is does, no one can log in except for root.

auth        required          /lib/security/pam_securetty.so

The pam_securetty.so module then prevents root logins from occurring on insecure terminals. This effectively disallows all root rlogin attempts for security reasons.

Tip

If you need to log in as root, use OpenSSH instead. For more information on the SSH protocol, see Chapter 24.

auth           required          /lib/security/pam_env.so

This line loads the pam_env.so module, which sets the environmental variables specified in /etc/security/pam_env.conf.

auth       sufficient        /lib/security/pam_rhosts_auth.so

The pam_rhosts_auth.so module then authenticates the user using .rhosts in the user’s home directory. If this succeeds, PAM immediately authenticates the rlogin session. If pam_rhosts_auth.so fails to authenticate the user, this failed authentication attempt is ignored.

auth        required        /lib/security/pam_stack.so service=system-auth

If the pam_rhosts_auth.so module fails to authenticate the user, the pam_stack.so module performs normal password authentication. The argument service=system-auth means the user must now pass through the PAM configuration for system authorization found in /etc/pam.d/system-auth.

Note

If you do not want to prompt for a password when the securetty check fails and determines that the user is trying to log in as root remotely, you can change the pam_securetty.so module from required to requisite.