Previous Section Next Section

4.5 Pluggable Authentication Modules (PAM)

Because there are so many ways to authenticate users, it's convenient to have a unified approach to authentication that can handle multiple authentication systems for different needs. The Pluggable Authentication Modules (PAM) system is one such approach.

PAM was originally developed by Sun, and implementations are available for Solaris, FreeBSD, and especially Linux, where most PAM development is now centered. PAM provides a library and API that any application can use to authenticate users against a myriad of authentication systems. Each authentication system that PAM knows about is implemented as a PAM module, which in turn is implemented as a dynamically-loaded shared library. PAM modules are available to authenticate users through:

  • /etc/passwd or /etc/shadow

  • NIS or NIS+

  • LDAP

  • Kerberos 4 or 5

  • An arbitrary Berkeley DB file[20]

    [20] If that's not enough layers for you, some applications, such as SMTP authentication in sendmail or access to mailboxes managed by the Cyrus imapd server, use the Cyrus SASL (Simple Authentication and Security Layer) authentication library, which can authenticate users with a separate database or through PAM! It is not inconceivable that you might find SASL using PAM using LDAP to authenticate a user's IMAP connection.

Each PAM-aware service is configured either in the /etc/pam.conf file or, more commonly, in its own file in the /etc/pam.d directory. For example, the PAM configuration file for the /bin/su command in Linux distributions is /etc/pam.d/su. A service named other is used to provide defaults for PAM-aware services that are not explicitly configured.

Here is an excerpt from /etc/pam.conf for the OpenSSH server:

sshd  auth     required    /lib/security/pam_env.so
sshd  auth     sufficient  /lib/security/pam_unix.so likeauth nullok
sshd  auth     required    /lib/security/pam_deny.so
sshd  account  required    /lib/security/pam_unix.so

sshd password required   /lib/security/pam_cracklib.so retry=3
sshd password sufficient /lib/security/pam_unix.so nullok use_authtok md5 shadow
sshd password required   /lib/security/pam_deny.so

sshd  session  required  /lib/security/pam_limits.so
sshd  session  required  /lib/security/pam_unix.so

Here's how the same excerpt looks in /etc/pam.d/sshd:

auth     required   /lib/security/pam_env.so
auth     sufficient /lib/security/pam_unix.so
auth     required   /lib/security/pam_deny.so

account  required  /lib/security/pam_unix.so

password required  /lib/security/pam_cracklib.so retry=3
password sufficient /lib/security/pam_unix.so nullok use_authtok md5 shadow
password required   /lib/security/pam_deny.so

session  required   /lib/security/pam_limits.so
session  required   /lib/security/pam_unix.so

The auth lines describe the authentication process for this service, which proceeds in the order specified. Modules marked required must run successfully for authentication to progress—if they fail, the user is considered unauthenticated and generally will be denied access. Multiple required modules can be specified; in these cases, all of the modules must run successfully. Modules marked sufficient, if run successfully, are sufficient to authenticate the user and end the authentication process.

Note the modules in this example:

pam_env

The first module run, pam_env, optionally sets or clears environment variables specified in /etc/security/pam_env.conf. This module is required—it must run successfully for authentication to proceed.

pam_unix

The next module run, pam_unix, performs authentication with the usual Unix password files, /etc/passwd and /etc/shadow. If this succeeds, it is sufficient to authenticate the user, and the process is complete.

pam_deny

The final authentication module, pam_deny, simply fails, ending the process with authentication unsuccessful.

This particular configuration file will also enforce any account aging or expiration rules of the system, and set resources limits on the user's sshd session. If sshd provided a password-changing function, this configuration file would also prevent the user from changing his password to an easily guessable one, and store passwords in /etc/shadow encrypted by the MD5 cryptographic hash function.

The PAM subsystem can be configured in a number of different ways. For instance, it is possible to require two or three separate passwords for some accounts[21] to combine a biometric method along with a passphrase, or to pick a different mechanism depending on the time of day. It is also possible to remove the requirement of a password for hardwired lines in highly secured physical locations. PAM allows the administrator to pick a policy that best matches the risk and technology at hand.

[21] This is highly annoying and of questionable value when the same user holds all of the passwords. This approach can be valuable when the passwords are assigned to different users, so that any login requires two or more people and creates a "witness" trail.

PAM can do a lot more than authentication, as these examples suggest. One of its strengths is that it clearly delineates four phases of the access process.

  • Verifying that the account is viable for the desired service at the desired time and from the desired location (the account phase)

  • Authenticating the user (the auth phase)

  • Updating passwords and other authentication tokens when necessary (the password phase)

  • Setting up and closing down the user's session (the session phase), which can include limiting resource access and establishing audit trails
    Previous Section Next Section