Programs which give users access to privileges of any sort need to be able to authenticate the users. When you log into a system, you provide your name and password, and the login process uses those to authenticate the login -- to verify that you are who you say you are. Other forms of authentication than passwords are possible, and it is possible for the passwords to be stored in different ways.

PAM, which stands for ``Pluggable Authentication Modules,'' is a way of allowing the system administrator to set authentication policy without having to recompile programs which do authentication. With PAM, you control how the modules are plugged into the programs by editing a configuration file.

Most Red Hat Linux users will never need to touch this configuration file. When you use RPM to install programs that need to do authentication, they automatically make the changes that are needed to do normal password authentication. However, you may want to customize your configuration, in which case you need to understand the configuration file.

There are four types of modules defined by the PAM standard. auth modules provide the actual authentication, perhaps asking for and checking a password, and set ``credentials'' such as group membership or kerberos ``tickets.'' account modules check to make sure that the authentication is allowed (the account has not expired, the user is allowed to log in at this time of day, etc.). password modules are used to set passwords. session modules are used once a user has been authenticated to make it possible for them to use their account, perhaps mounting the user's home directory or making their mailbox available.

These modules may be stacked, so that multiple modules are used. For instance, rlogin normally makes use of at least two authentication methods: if ``rhosts'' authentication succeeds, it is sufficient to allow the connection; if it fails, then standard password authentication is done.

New modules can be added at any time, and PAM-aware applications can then be made to use them. For instance, if you have a one-time-password calculator system, and you can write a module to support it (documentation on writing modules is included with the system), PAM-aware programs can use the new module and work with the new one-time-password calculators without being recompiled or otherwise modified in any way.

Each program using PAM defines its own ``service'' name. The login program defines the service type login, ftpd defines the service type ftp, etc. In general, the service type is the name of the program used to access the service, not (if there is a difference) the program used to provide the service.

The directory /etc/pam.d is used to configure all PAM applications. (This used to be
/etc/pam.conf in earlier PAM versions; while the pam.conf file is still read if no
/etc/pam.d/ entry is found, its use is deprecated.) Each application (really, each service) has its own file. A file looks like this:

#auth      required  /lib/security/pamsecuretty.so
auth      required  /lib/security/pampwdb.so shadow nullok
auth      required  /lib/security/pamnologin.so
account   required  /lib/security/pampwdb.so
password  required  /lib/security/pamcracklib.so
password  required  /lib/security/pampwdb.so shadow ¬
                                         nullok useauthtok
session   required  /lib/security/pampwdb.so

The first line is a comment. Any line that starts with a # character is a comment. Lines two through four stack up three modules to use for login authorization. Line two 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. Line three causes the user to be asked for a password and the password checked. Line four checks to see if the file /etc/nologin exists, and if it does, displays the contents of the file, and if the user is not root, does not let him or her log in.

Note that all three modules are checked, even if the first module fails. This is a security decision---it is designed to not let the user know why their authentication was disallowed, because knowing why it was disallowed might allow them to break the authentication more easily. You can change this behavior by changing required to requisite; if any requisite module returns failure, PAM fails immediately without calling any other modules.

The fifth line causes any necessary accounting to be done. For example, if shadow passwords have been enabled, the pam_pwdb.so module will check to see if the account has expired, or if the user has not changed his or her password and the grace period for changing the password has expired.

The sixth line subjects a newly changed password to a series of tests to ensure that it cannot, for example, be easily determined by a dictionary-based password cracking program.

The seventh line (which we've had to wrap) specifies that if the login program changes the user's password, it should use the pam_pwdb.so module to do so. (It will do so only if an auth module has determined that the password needs to be changed---ie, if a shadow password has expired.)

The eighth and final line specifies that the pam_pwdb.so module should be used to manage the session. Currently, that module doesn't do anything; it could be replaced (or supplemented by stacking) by any necessary module.

Note that the order of the lines within each file matters. While it doesn't really matter much in which order required modules are called, there are other control flags available. While optional is rarely used, and never used by default on a Red Hat Linux system, sufficient and requisite cause order to become important.

Let's look at the auth configuration for rlogin:

auth  required    /lib/security/pamsecuretty.so
auth  sufficient  /lib/security/pamrhostsauth.so
auth  required    /lib/security/pampwdb.so shadow nullok
auth  required    /lib/security/pamnologin.so

That looks almost like the login entry, but there's an extra line specifying an extra module, and the modules are specified in a different order.

First, pam_securetty.so keeps root logins from happening on insecure terminals. This effectively disallows all root rlogin attempts. If you wish to allow them (in which case we recommend that you either not be internet-connected or be behind a good firewall), you can simply remove that line.

Second, pam_nologin.so checks /etc/nologin, as specified above.

Third, if pam_rhosts_auth.so authenticates the user, PAM immediately returns success to rlogin without any password checking being done. If pam_rhosts_auth.so fails to authenticate the user, that failed authentication is ignored.

Finally (if pam_rhosts_auth.so has failed to authenticate the user), the pam_pwdb.so module performs normal password authentication.

Note that if you do not want to prompt for a password if the securetty check fails, you can change the pam_securetty.so module from required to requisite

For security reasons, rexec is not enabled in Red Hat Linux 6.0. Should you wish to enable it, you will need to comment out one line in the file /etc/pam.d/rexec. Here is a sample of the file (note that your file may differ slightly):

#auth       required     /lib/security/pampwdb.so shadow nullok
auth       required     /lib/security/pamnologin.so
account    required     /lib/security/pampwdb.so

To enable rexec, the line referring to the pam_nologin.so module must be commented out:

#auth       required     /lib/security/pampwdb.so shadow nullok
#auth       required     /lib/security/pamnologin.so
account    required     /lib/security/pampwdb.so

After this file is modified, rexec will be enabled.

Please Note: If your /etc/pam.d/rexec file contains a line referring to the pam_securetty.so module, you will not be able to rexec as root. To do so, you must also comment out the line referring to the pam_securetty.so module.

More Information