Section 8.10. PAM

8.10. PAM

PAM (Pluggable Authentication Modules) provides an interface that programs can use to connect to whatever authentication methods are desired. Authentication can be as trivial as the user typing "hello world", as complex as biometrics, or as prosaic as passwords. I think PAM is a great boon for system administrators, and I'm excited to see it in CVS.

PAM works by having the system administrator define which modules she wants run for each application. The application calls PAM, PAM checks its configuration files, and then PAM calls the relevant modules. If the module requires additional data (such as a password), the module requests it from PAM, and PAM requests it from the application, then hands it to the module. The module runs, and reports its results to PAM.

PAM combines the results of all the modules it's configured to run for the application, and then returns a single combined success or failure to the application, depending on a strict set of criteria. The criteria are also configured by the system administrator.

At the moment, PAM support in CVS is experimental, and is limited to the fallback option in the pserver connection method. To get PAM support for CVS, configure your CVS executable with --enable-pam, having SystemAuth set to yes in your CVSROOT/config file, and leave CVSROOT/passwd empty.

My article "Introduction to PAM" explains how to configure PAM on your system, and it is available at http://www.linuxdevcenter.com/pub/a/linux/2001/09/27/pamintro.html.

The default PAM configuration file for CVS is /etc/pam.d/cvs. If your version of PAM uses a single /etc/pam.conf file instead of a separate file for each application, the application name is cvs. The PAM application name (or configuration file name) can be configured at compilation time with -with-hardcoded-pam-service-name=name. Use ./configure to set the PAM compilation options. Make sure you read the INSTALL file in the CVS source code, and the installation instructions in Chapter 2.

Each PAM configuration file contains a series of lines. Those lines have the format module-type control-flag module-path arguments. The module type defines the aspect of authentication that the line controls. The module path and arguments control what is done for that line. The control flag specifies how PAM should react to the results of the module defined in the module path.

CVS uses the auth, account, and session module types, but not passwd. This means that the system administrator will be responsible for defining and updating the authentication token for each user. The module types are:

account

Nonauthentication account management, such as limiting the maximum number of users or restricting root access

auth

User authentication, group assignment, and other authentication- and permission-related tasks

session

Anything the user needs to have done to connect, such as mounting drives or logging connections

passwd

Updating the authentication token

PAM can call any number of modules for each module type, but calls only one module type at a time: it will call all auth modules when CVS is identifying the user, or all session modules when CVS is starting a connection. The control-flag for each module controls how PAM calculates success or failure for that module, and for the stack of all modules of the type. If you're accustomed to using PAM, there's a complicated syntax for the control flags that gives you truly fine-grained control. If not, use these four flags:

optional

Not critical to the success or failure of the stack. If at least one nonoptional module succeeds or fails, the result of this module is ignored when calculating the success or failure of the stack.

required

The module must succeed for the stack of this module type to succeed. If this module fails, all other modules in the stack are executed but the stack is considered to fail.

requisite

The module must succeed for the stack of this module type to succeed. No later module of its type is executed; failure is reported immediately. The return value is that of the first module in the stack to fail.

sufficient

Success of this module is sufficient for the stack of this module type to succeed. If no previous required module has failed, no other modules of this module type are invoked. (This overrides the required execution of all other modules.) Failure of this module does not inherently prevent the stack from succeeding.

A basic PAM configuration might be:

 account    required    /usr/lib/security/pam_unix.so auth       requisite   /usr/lib/security/pam_nologin.so auth       required    /usr/lib/security/pam_unix.so session    required    /usr/lib/security/pam_unix.so 

PAM has hundreds of modules available, including modules to authenticate users via LDAP or Kerberos, cryptography cards and buttons, or classic Unix authentication. Every time I look, there are even more interesting and useful modules. I use the Linux-PAM web site at http://www.kernel.org/pub/linux/libs/pam/, but you can also find out about PAM news at http://www.openwall.com/pam/ or http://www.sun.com/software/solaris/pam/.

The PAM method has all the security problems of the pserver method. The password (or other security token) is still stored and transmitted with trivial encoding, and there is no easy method within CVS of updating the passwords.

If you use the PAM system, or have comments about it, please consider mailing them at the CVS mailing lists: [e-mail] or [e-mail]. The developers are actively requesting feedback.