What are some examples of PAM Configuration Files?

​

Below is a sample PAM application configuration file:

Raw

<code>#%PAM-1.0 auth required pam_securetty.so auth required pam_unix.so shadow 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</code>

The first line is a comment as denoted by the hash mark (#) at the beginning of the line.

Lines two through four stack three modules for login authentication.

<code>auth required pam_securetty.so</code>

This module makes sure that if the user is trying to log in as root, the tty on which the user is logging in is listed in the <code>/etc/securetty</code> file, if that file exists.

<code>auth required pam_unix.so shadow nullok</code>

This module prompts the user for a password and then checks the password using the information stored in <code>/etc/passwd</code> and, if it exists, <code>/etc/shadow</code> . The <code>pam_unix.so</code> module automatically detects and uses shadow passwords to authenticate users.

The argument <code>nullok</code> instructs the <code>pam_unix.so</code> module to allow a blank password.

<code>auth required pam_nologin.so</code>

This is the final authentication step. It verifies whether or not the file <code>/etc/nologin</code> exists. If <code>nologin</code> 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 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.

<code>account required pam_unix.so</code>

This module performs any necessary account verification. For example, if shadow passwords have been enabled, the account component of the <code>pam_unix.so</code> module checks to see if the account has expired or if the user has not changed the password within the grace period allowed.

<code>password required pam_cracklib.so retry=3</code>

If a password has expired, the password component of the <code>pam_cracklib.so</code> module 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. If it fails this test the first time, it gives the user two more chances to create a strong password, as specified in the <code>retry=3</code> argument.

<code>password required pam_unix.so shadow nullok use_authtok</code>

This line specifies that if the program changes the user's password, it should use the <code>password</code> component of the <code>pam_unix.so</code> module to do so. This only happens if the <code>auth</code> portion of the <code>pam_unix.so</code> module has determined that the password needs to be changed.

The argument <code>shadow</code> tells the module to create shadow passwords when updating a user's password.

The argument <code>nullok</code> instructs 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, <code>use_authtok</code> , provides a good example of the importance of order when stacking PAM modules. This argument tells 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 <code>pam_cracklib.so</code> test for secure passwords before being accepted.

<code>session required pam_unix.so</code>

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

The next sample configuration file illustrates <code>auth</code> module stacking for the <code>rlogin</code> program.

<code>#%PAM-1.0 auth required pam_nologin.so auth required pam_securetty.so auth required pam_env.so auth sufficient pam_rhosts_auth.so auth required pam_stack.so service=system-auth</code>

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

<code>auth required pam_securetty.so</code>

The <code>pam_securetty.so</code> module prevents the root user from logging in on insecure terminals. This effectively disallows all root <code>rlogin</code>attempts due to the application's limited security safeguards.

Tip: To log in remotely as the root user, use OpenSSH instead.

<code>auth required pam_env.so</code>

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

<code>auth sufficient pam_rhosts_auth.so</code>

The <code>pam_rhosts_auth.so</code> module authenticates the user using <code>.rhosts</code> in the user's home directory. If this succeeds, PAM immediately considers the authentication to have succeeded. If <code>pam_rhosts_auth.so</code> fails to authenticate the user, the authentication attempt is ignored.

<code>auth required pam_stack.so service=system-auth</code>

If the <code>pam_rhosts_auth.so</code> module fails to successfully authenticate the user, the <code>pam_stack.so</code> module performs normal password authentication.

The argument <code>service=system-auth</code> indicates that the user must now pass through the PAM con- figuration for system authentication as found in <code>/etc/pam.d/system-auth</code> .

Tip: To prevent PAM from prompting for a password when the securetty result fails, change the <code>pam_securetty.so</code> module from <code>required to requisite</code>.