PAM is the Pluggable Authentication Modules system. It enables the addition of a number of advanced security features across the whole Linux system without the need to recode individual services. All security conscious programs (such as login, su, and ftp) are configured by PAM to do a variety of authentication and security checks.
When a service such as login is used, PAM will check its configuration files to determine how to authenticate the user. For instance, PAM may authenticate by checking shadow passwords, Kerberos, Winbind, Samba, and so on. After the method of authentication is determined, PAM returns an answer to the service to indicate whether the user was authenticated.
All the PAM configuration files are located in /etc/pam.d. Every application or service that can use PAM has a file entry in /etc/pam.d as well. Some of the most common entries that can be found under /etc/pam.d include chfn, chsh, halt, linuxconf, login, passwd, ppp, reboot, rexec, rlogin, rsh, shutdown, su, xdm, and xscreensaver. If installed, you may even find KDE, Samba, and SSH here as well. Looking at these files, you will see four columns of information: module-type
, control-flag, module-path
, and arguments
. Take a look at the following example of the login entry under /etc/pam.d:
#%PAM-1.0 auth required /lib/security/pam_securetty.so auth required /lib/secuirty/pam_pwdb.so shadow nullok auth required /lib/security/pam_nologin.so account required /lib/security/pam_pwdb.so password required /lib/security/pam_cracklib.so password required /lib/security/pam_pwdb.so nullok use_authtok session required /lib/security/pam_pwdb.so session optional /lib/security/pam_console.so
The following subsections describe each field.
There are currently four types of modules that you will find under the module-type
column in your PAM configuration files, shown inTable 39-5.
Table 39-5. Module types
Module |
Description |
---|---|
|
This module type provides two ways of authenticating the user. First, it establishes that the user is indeed who the user claims to be. It does this by instructing the application to prompt the user for a password. The module can then grant group membership (independent of /etc/groups) or other privileges through its credential granting properties. |
|
This module restricts authentication-based account management. It is typically used to restrict or permit access to a service based on the time of day, the maximum number of users, or even the location of the user (for instance, allowing user root to log in only from the console). |
|
This module performs duties that need to be done for the user before she can be given access. Services that are affected by this include the logging of information about a user, mounting directories, and so on. |
|
This module is required for updating the authentication token associated with each user. There is typically one module for each challenge or response, based on the authentication ( |
The control-flag
column is used to indicate how the PAM library reacts to the success or failure of the module with which it is associated. The four flags that are used to specify the module actions are shown in Table 39-6.
Table 39-6. Control flags
Flag |
Description |
---|---|
|
This flag marks the module as not being critical to the success or failure of the user's application for service. In fact, Linux-PAM will ignore such a module when determining whether the module stack succeeds or fails. |
|
This indicates that the success of the module is required for the module-type facility to succeed. But if this module fails, the failure will not be apparent to the user until all the modules of the same module type have been executed. |
|
This is similar to |
|
This indicates that the Linux-PAM library is satisfied that this module type has succeeded in its purpose. If no previous module has failed, no more stacked modules of this type are invoked. If this module fails, the result is not deemed fatal to the application. |
The module-path
is the pathname to the dynamically loadable module. The default directory containing the module defaults to /lib/security, unless another path is mentioned. Typically, the full path /lib/security is listed regardless.
The argument
column of each entry lists arguments that are passed to the module when the module is invoked. Typically, these arguments are optional and are specific to each given module. If an argument is invalid, the module ignores it. If such an error is made, the module is required to write the error to syslog, the system log daemon. The five generic arguments that are often used and understood by most modules are shown in Table 39-7.
Table 39-7. Arguments
Argument |
Description |
---|---|
|
Use the syslog call to log debugging information to the system log files. |
|
Instruct the module not to give warning messages to the application. |
|
The module should attempt authentication with the previously typed password from the preceding |
|
The module should not prompt the user for a password. Instead, it should obtain the previously typed password from the preceding |
|
Instructs the module to take the clear text authentication token entered by a previous module and use it to generate an encrypted (or decrypted) key to safely store or retrieve the authentication token required for the module. The |
A special argument listed in the example for auth
was shadow
. This refers to support for shadow passwords, which is supported by pam_pwdb.so. Shadow passwords utilize several methods to increase system security. They make system password files more difficult to break into for system password information, by replacing the password field of /etc/passwd (with an x
) and creating the file /etc/shadow, readable only by root, to contain the password hash.
One of the best uses of LDAP is to centralize your authentication information base. It makes user administration easier and smarter. The authentication method should be changed in the PAM mechanism, and you need to change the way to search the tree where the user's information (password, UID, GID, home, shell) is placed. Multiple client platforms—Solaris, Linux, AIX, and so on—can use an LDAP server for authentication
The following examples require a fully functional OpenLDAP server, a posix
account object already created in your directory, and properly working client-side queries.
Two packages are needed to get LDAP auhentication working:
Used by nsswitch.conf to retrieve information from LDAP servers
The PAM module that can be used to take advantage of LDAP in many PAM-aware applications
Both are available under GPL license at the maintainer's site, www.padl.com. The configuration, compilation, and installation process is simple and can be determined from the site's documentation.
Debian, Red Hat, and many other distributions make available precompiled nss_ldap and pam_ldap packages.
With the packages installed, change the nsswitch.conf file to the following:
passwd: files ldap group: files ldap shadow: files ldap
To test whether nss_ldap is retrieving LDAP information, try:
# getent passwd
...(you should see the /etc/passwd accounts here)
cxp7:x:2645:347:JACQUELINE:/u/cxp7:/bin/bash
d026:x:1130:672:CARLOS:/u/d026:/bin/bash
ima3:x:548:224:PIERRE:/u/ima3:/bin/bash
...
Now change the /etc/pam.d/login file:
auth required pam_securetty.so auth required pam_nologin.so auth sufficient pam_ldap.so auth required pam_unix_auth.so try_first_pass account sufficient pam_ldap.so account required pam_unix_acct.so password required pam_ldap.so session sufficient pam_ldap.so session required pam_unix_session.so
For users who log in using Gnome Display Manager, the file /etc/pam.d/gdm has to be modified:
auth sufficient pam_ldap.so auth required pam_nologin.so auth required pam_env.so auth required pam_unix_auth.so account sufficient pam_ldap.so account required pam_unix_acct.so password required pam_ldap.so session sufficient pam_ldap.so session required pam_unix_session.so
There are many configurable files under /etc/pam.d. It's possible to authenticate FTP, su, SSH, and lots of other stuff over LDAP. This is outside the scope of LPI, however.