Authentication with PAM 39

so only if anauthmodule has determined that the password needs to be changed ---for example, if a shadow password has expired.)

The eighth and final line specifies that thepam_pwdb.somodule 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 avail-able. 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 authconfiguration forrlogin:

auth required /lib/security/pam_securetty.so auth sufficient /lib/security/pam_rhosts_auth.so

auth required /lib/security/pam_pwdb.so shadow nullok auth required /lib/security/pam_nologin.so

That looks almost like theloginentry, 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 termi-nals. This effectively disallows all rootrloginattempts. If you wish to allow them (in which case we recommend that you not be Internet-connected or be behind a good firewall), you can simply remove that line.

Second, if pam_rhosts_auth.so authenticates the user, PAM imme-diately returns success to rlogin without any password checking. If pam_rhosts_auth.so fails to authenticate the user, that failed authenti-cation is ignored.

Third, if pam_rhosts_auth.so has failed to authenticate the user, the pam_pwdb.somodule performs normal password authentication.

Finallypam_nologin.sochecks/etc/nologin, as specified above.

Note that if you do not want to prompt for a password if thesecurettycheck fails, you can change thepam_securetty.somodule from required to requisite.

2.6.4 Shadow Passwords

The pam_pwdb.so module will automatically detect that you are using shadow passwords and make all necessary adjustments. Please refer to Section 2.7, Shadow Utilities for more information.

2.6.5

and PAM

For security reasons,rexecis not enabled in Red Hat Linux 6.2. 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):

#%PAM-1.0

auth required /lib/security/pam_pwdb.so shadow nullok auth required /lib/security/pam_nologin.so

account required /lib/security/pam_pwdb.so

To enable^rexec, the line referring to thepam_nologin.somodule must be com-mented out:

#%PAM-1.0

auth required /lib/security/pam_pwdb.so shadow nullok

#auth required /lib/security/pam_nologin.so account required /lib/security/pam_pwdb.so

After this file is modified,rexecwill be enabled.

Please Note

If your/etc/pam.d/rexecfile contains a line referring to thepam_securetty.somodule, you will not be able torexecas root. To do so, you must also comment out the line referring to thepam_securetty.somodule.

More Information

This is just an introduction to PAM. More information is included in the /usr/doc/pam*directory, including a System Administrators’ Guide, a Module

Section 2.7:Shadow Utilities 41

Writers’ Manual, an Application Developers’ Manual, and the PAM standard, DCE-RFC 86.0.

2.7 Shadow Utilities

Shadow passwords are a method of improving system security by moving the en-crypted passwords (normally found in/etc/passwd) to/etc/shadowwhich is readable only by root. During the installation of Red Hat Linux, you were given the option of setting up shadow password protection on your system.

Theshadow-utilspackage contains a number of utilities that support:

• Conversion from normal to shadowed passwords and back (pwconv, pwun-conv)

• Verification of the password, group, and associated shadow files (pwck,grpck)

• Industry-standard methods of adding, deleting and modifying user accounts (useradd, usermod, anduserdel)

• Industry-standard methods of adding, deleting, and modifying user groups (groupadd, groupmod, andgroupdel)

• Industry-standard method of administering the/etc/groupfile (gpasswd)

Please Note

There are some additional points of interest concerning these utilities:

• The utilities will work properly whether shadowing is enabled or not.

• The utilities have been slightly modified to support Red Hat’s user private group scheme. For a description of the modifications, please see theuseraddman page. For more information on user private groups, please turn to Section 2.3.3, User Private Groups.

• Theadduserscript has been replaced with a symlink to/usr/sbin/useradd.

2.8 Building a Custom Kernel

Many people new to Linux often ask, "why should I build my own kernel?" Given the advances that have been made in the use of kernel modules, the most accurate response to that question is, "unless you know why you need to build your own kernel, you probably don’t." So unless you have a specific reason to build a customized kernel (or you’re just the curious sort), you may skip ahead to Section 2.9, Sendmail.

In the past, you would need to recompile the kernel if you added new hardware on your system. The kernel was, in other words, static. Improvements in the Linux 2.0.x kernels allowed for much of the drivers for hardware to be modularized into compo-nents that could only be inserted on demand. However, there were major problems with having multiple kernels on your system that had been compiled for different advancements (a good case being SMP versus UP kernels). Further advancements with the modularization of the Linux 2.2.x kernel have allowed for multiple kernels to more easily co-exist (though not share modules).