|
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:
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:
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.
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.
|
|
|