Editor's note: This is the second in a series of article on Pluggable Authentication Modules. In part one, Jennifer introduced PAM and showed how to get started. In this article, she walks us through some of the more useful modules.
Traditional user authentication is programmed directly into applications. Using PAM (Pluggable Authentication Modules), applications can be developed with a PAM interface, and the system administrator can choose any number of PAM modules to do authentication and other tasks.
PAM was designed for authentication, and it remains the most common function of PAM modules. Programmers being programmers, there are now PAM modules to do much more than authentication. A variety of security tasks can be done through modules, and there are utilities for session management.
pam_cracklib.so should be used in most systems that are connected to a network. pam_env.so is an easily underestimated module that allows the system administrator to adjust the user environment.
pam_cracklib.so checks passwords for strength and security.
Use pam_cracklib.so in the password section of a PAM configuration file. The module uses the libcrack code to test whether the password is easily cracked, then runs additional tests against the old password and against system administrator determined parameters. pam_cracklib.so relies on /usr/lib/cracklib_dict, and has only a password component.
As well as the libcrack tests, pam_cracklib.so checks whether the new password is the old password with a change of case, whether it is a palindrome of the old password, whether it satisfies the difok argument, whether it passes the minimum length check, whether it's been recently used, and whether it's a simple rotation of the old password.
difok = Nminlen = Nmd5 passwords, a longer password is recommended.dcredit, ucredit, lcredit and ocredit#
# /etc/pam.d/example
#
password required pam_cracklib.so minlen=15 ocredit=2
password required pam_unix.so use_authtok md5pam_env.so allows you to set or unset environment variables using strings, existing variables, or PAM items.
The settings for this module are in /etc/security/pam_env.conf (though the argument conffile can override this). Syntax for this file is:
VARIABLE DEFAULT=value OVERRIDE=value
|
Previously in this series: Introduction to PAM -- Pluggable Authentication Modules provide a solution to the difficulties of user authentication. Jennifer Vesperman introduces PAM and helps you get started. |
The default settings are used if the override settings are not available. Environment variables can be referred to using ${variable}, and PAM items using @{variable}.
Valid PAM items for use with /etc/security/pam_env.conf are: PAM_USER, PAM_USER_PROMPT, PAM_TTY, PAM_RUSER, and PAM_RHOST. If pam_env.so is used on login, the ${USER} environment variable is not yet set. Use @{PAM_USER} instead.
The readenv argument toggles whether pam_env.so reads the environment file, /etc/environment, by default. The envfile argument allows you to use a different environment file. This file uses KEY=VALUE syntax to set the values of environment variables.
The pam_env.so module has only an auth component.
|
One use of pam_env.so is setting per-user environment variables. Setting $TMP and $TMPDIR variables for each user can provide security -- well-behaved programs will use the per-user temporary directories, which you can lock away from other users. ($TMP and $TMPDIR both refer to the temporary directories, the name of the variable was standardized late.)
#
# /etc/pam.d/login
# (This is a fairly minimal 'login' configuration)
#
auth requisite pam_securetty.so
auth requisite pam_nologin.so
auth required pam_env.so
auth required pam_unix.so nullok
account required pam_unix.so
session required pam_unix.so
password required pam_cracklib.so retry=3 minlen=6
password required pam_unix.so use_authtok nullok obscure
#
# /etc/security/pam_env.conf
#
# Set temp directories.
#
TMP DEFAULT=/tmp OVERRIDE=/tmp/@{PAM_USER}
TMPDIR DEFAULT=/tmp OVERRIDE=/tmp/@{PAM_USER}
#
# /etc/profile
#
# Create the temp directories if they don't exist.
# NOTE: this code doesn't test that they belong
# to the user!
#
test -d $TMP || mkdir $TMP
test -d $TMPDIR || mkdir $TMPDIRThe most common modules provide some form of user authentication, or modify user authentication in some way.
This module enables FTP-style anonymous login. If the user name is "ftp" or "anonymous", it allows automatic access and parses the password as an email address for logging. It only has an auth component.
Parameters include users, which provides additional login names for anonymous login, and ignore, which ignores the email address/password.
pam_krb4.so interfaces with Kerberos authentication. It has auth, session, and password components. It relies on Kerberos include files, and on libkrb, libdes, libcom_err, and libadm.
The auth component requests a ticket-granting ticket from the Kerberos server, uses it to attempt to retrieve a local host key, and verifies it with the local key file (if the file exists). It provides a ticket file for later use, and deletes that on logout.
The password component uses the old password to request a session key for the Kerberos password changer, and uses the key to send the new password.
The session component deletes the Kerberos ticket on logout. (This is redundant with the auth component.)
This module does standard Unix password authentication and session management, performing the same functions as the pam_unix.so module described in Introduction to PAM. pam_pwdb.so uses the password database library -- libpwdb -- instead of the traditional Unix password libraries.
The libpwdb library implements configurable authentication, using /etc/password, /etc/shadow, and network authentication tools like NIS and RADIUS.
pam_pwdb.so has all four components, and the same arguments as pam_unix.so.
pam_radius.so connects PAM to Radius authentication/accounting servers for accounting (but not authentication) purposes. It only has a session component. pam_radius.so should be used as the last required session module for the application it authenticates. This module requires /etc/raddb/server and /etc/raddb/dictionary, and expects libpwdb.
The modules in this section limit, control or adjust access to the calling applications.
This module controls access by user name, host name, domain names, IP addresses, and terminal lines. It is configured in /etc/security/access.conf. This module only has an account component. It is recommended for use on NIS machines and other servers where accounts need to exist, but do not have login capability.
This module enables root to be locked out of any tty but the one in /etc/securetty -- usually console. The application using this module must correctly set the PAM item PAM_TTY. This module only has an auth component, and should be one of the required modules, before any sufficient modules.
pam_time.so allows access restrictions by time. Restriction options include day of the week, time of day, user, service, and tty. Configure this module in /etc/security/time.conf. It only has an account component.
|
This module is intended for use with the su program. It restricts access to the superuser account to the wheel group, or to group ID "0" (if there is no wheel group). It only has an auth component. Wheel is the traditional name for the group authorized to su to root.
Arguments:
PAM_SUCCESS, which allows su without passwords, instead of PAM_IGNORE. This has obvious security implications.su.uid of a program, rather than of the user.These are modules that don't affect security, but which make life easier or better for the user or the system administrator.
This module allows the administrator to set resource limits on users. It relies on libpwdb, and on kernel support for resource limits. It should be used as a required session module.
pam_limits.so is configured in /etc/security/limits.conf. The first entry which matches the user is the one which will apply to that user. The syntax is:
domain type item valueTerm expansion:
* -- all- -- bothfsize -- filesizememlock -- max locked memory address spacenofile -- open filesrss -- resident set sizenproc -- number of processesas -- address spacepam_mail.so provides the "you have new mail" service to the user. It has both session and auth components, and should be treated as an optional module. Arguments include dir=[directory] (for the mail directory), and quiet (only report if there is new mail, don't report the absence of mail or old mail).
This module creates home directories on the fly for authenticated users, and is particularly useful for batch addition of users. pam_mkhomedir.so requires the arguments 'skel=[directory]', for a skeleton home directory, and 'umask=[octal mask]'.
|
|
PAM modules provide flexibility in authentication and session management. See the further reading section, or the PAM manuals on your system, for more information on the modules.
PAM is built into many Linux distributions, including Caldera 1.3, 2.2 and later; Debian 2.2 and later; Turbo Linux 3.6 and later; Red Hat 5.0 and later; and SuSE 6.2 (partial support). FreeBSD supports PAM from version 3.1.
If your system is one of the ones which has built in PAM, you are probably already using many PAM modules. Examine /etc/pam.d or /etc/pam.conf for details of what your system is already doing with PAM.
Jennifer Vesperman is the author of Essential CVS. She writes for the O'Reilly Network, the Linux Documentation Project, and occasionally Linux.Com.
Return to the Linux DevCenter.
Copyright © 2009 O'Reilly Media, Inc.
