PAM - Pluggable Authentication Modules
 

PAM is designed to provide the system administrator with a great deal of flexibility in configuring the privilege granting applications of their system. The local configuration of those aspects of system security controlled by PAM is contained in the /etc/pam.d directory. In this section we discuss the correct syntax of and generic options respected by entries to these files.
 
When you look into the directory /etc/pam.d, you'll see a list of files. Each file refers to a service that requieres some kind of authentification. The names of the files in /etc/pam.d usually match the name of the service they configure. So is /etc/pam.d/login the configuration file for the login(1) application, passwd configures the passwd(1) utility, and so on.
 
It is possible to symbolically link different services configuration files to a single file. This makes it easier to keep the system policy for access consistent across different applications. You can limit read access to individual PAM configuration files using the file protections of the filesystem as an easy way to limit services only to specific groups of users.
 

A general configuration line of the /etc/pam.d/* files has the following form:
 

module-type   control-flag   module-path   arguments 

One of (currently) four types of modules:

The control-flag is used to indicate how the PAM library will react to the success or failure of the module it is associated with. Since modules can be stacked (modules of the same type execute in series, one after another), the control-flags determine the relative importance of each module. The application is not made aware of the individual success or failure of modules. Instead, it receives a summary success or fail response from the PAM library. The order of execution of these modules is that of the entries in the /etc/pam.conf file; earlier entries are executed before later ones. As of PAM v0.60, this control-flag can be defined with one of two syntaxes.
 
The simpler (and historical) syntax for the control-flag is a single keyword defined to indicate the severity of concern ssociated with the success or failure of a specific module. There are four such keywords: required, requisite, sufficient and optional.
 
The PAM library interprets these keywords in the following manner:

The path-name of the dynamically loadable object file; the pluggable module itself. If the first character of the module path is /, it is assumed to be a complete path. If this is not the case, the given module path is appended to the default module path: /lib/security. You will see descriptions of the most important modules in the next section.
 
The arguments are a list of tokens that are passed to the module when it is invoked. Much like arguments to a typical Linux shell command. Generally, valid arguments are optional and are specific to any given module. Invalid arguments are ignored by a module, however, when encountering an invalid argument, the module is required to write an error to syslog(3).
 
Most modules recognize a set of generic arguments:
 

You learned in the previous section, that PAM is organized around modules resposibe for different tasks of user authentification. In this section we'll list the modules used by the SuSE standard installation. Please note, that there are more modules available than discussed in this section. Refer to the PAM documentation (online or in /usr/doc/packages/pam) to learn more about modules not listed here.
 

This module allows you to (un)set arbitrary environment variables using fixed strings, the value of previously set environment variables and/or PAM_ITEMs.
 
This is controlled by a configuration file (by default, /etc/security/pam_env.conf but can be overriden with the conffile argument). Each line starts with the variable name, there are then two possible options for each variable DEFAULT and OVERRIDE.
 

VARIABLE   [DEFAULT=[value]]  [OVERRIDE=[value]] 

This module intercepts the user's name and password. If the name is ftp or anonymous, the user's password is broken up at the @ delimiter into a PAM_RUSER and a PAM_RHOST part; these pam-items being set accordingly. The username is set to ftp. In this case the module succeeds. Alternatively, the module sets the PAM_AUTHTOK item with the entered password and fails.
 
The behavior of the module can be modified with the following flags:
 

This module, through the PAM open-session hook, sets limits on the system resources that can be obtained in a user session. Its actions are dictated more explicitly through the configuration file /etc/security/limits.conf. Through the contents of the configuration file resource limits are placed on users' sessions. The user root is not affected by this restriction.
 
In order to use this module the system administrator must first create a root-only-readable file (default is /etc/security/limits.conf). This file describes the resource limits the superuser wishes to impose on users and groups.
 
Each line of the configuration file describes a limit for a user in the form:

domain     type      item    value 

The list-file module provides a way to deny or allow services based on an arbitrary file. Other than the modules discussed so far, this module does not have a configuration file. The behavoiur is controlled by it's command line options only. The module recognizes the following parameters:
 

This module provides the you have new mail service to the user. It can be plugged into any application that has credential hooks. It gives a single message indicating the newness of any mail it finds in the user's mail folder. This module also sets the PAM environment variable, MAIL, to the user's mail directory.
 
Although the module supplies functions for the authentication management group of functions, it cannot be used to authenticate a user; its authentication function instructs libpam to simply ignore it when authenticating the user.
 
The behavior of this module can be modified with one of the following flags:

Provides standard Unix nologin authentication. If the file /etc/nologin exists, only root is allowed to log in; other users are turned away with an error message. All users (root or otherwise) are shown the contents of /etc/nologin. If the file /etc/nologin does not exist, this module succeeds silently.
 
In order to make this module effective, all login methods should be secured by it. It should be used as a required method listed before any sufficient methods in order to get standard Unix nologin semantics.
 

This module is very dangerous. It should be used with extreme caution. Its action is always to permit access. It does nothing else.
 
No matter what management group, the action of this module is to simply return PAM_SUCCESS -- operation successful.
 
In the case of authentication, the user's name will be acquired. Many applications become confused if this name is unknown.
 
It is seldom a good idea to use this module. However, it does have some legitimate uses. For example, if the system-administrator wishes to turn off the account management on a workstation, and at the same time continue to allow logins, then this module should be used.
 

This module performs the standard network authentication for services, as used by traditional implementations of rlogin and rsh etc.
 
The authentication mechanism of this module is based on the contents of the files /etc/hosts.equiv and ~/.rhosts. Firstly, hosts listed in the former file are treated as equivalent to the localhost. Secondly, entries in the user's own copy of the latter file is used to map remote-host remote-user pairs to that user's account on the current host. Access is granted to the user if their host is present in /etc/hosts.equiv and their remote account is identical to their local one, or if their remote account has an entry in their personal configuration file.
 
Some restrictions are applied to the attributes of the user's personal configuration file: it must be a regular file; it must be owned by the superuser (root) or the user; it must not be writable by any user besides its owner.
 
In the case of root-access, the /etc/host.equiv file is ignored unless the hosts_equiv_rootok option should be used. Instead, the superuser must have a correctly configured personal configuration file.
 
The behavior of the module is modified by the following flags:

This module is for use in situations where the superuser wishes to gain access to a service without having to enter a password.
 
This module authenticates the user if their user ID is 0. Applications that are created setuid-root generally retain the user ID of the user but run with the authority of an enhanced effective-uid. It is the real uid that is checked.
 
In the case of the su application the historical usage is to permit the superuser to adopt the identity of a lesser user without the use of a password. To obtain this behavior under PAM this module should be used.
 

This module provides standard Unix securetty checking, which causes authentication for the superuser (root) to fail unless PAM_TTY is set to a string listed in the /etc/securetty file. For all other users, it succeeds.
 
For canonical usage, should be listed as a required authentication method before any sufficient authentication methods.
 

This module checks if the users login-shell (like listed in /etc/passwd) is a valid login-shell. Authentication is granted if the users shell is listed in /etc/shells. If no shell is in /etc/passwd (empty), the /bin/sh is used (following ftpd's convention).
 
This module also makes sure that /etc/shells is a plain file and not world writable. The file /etc/shells is a text file which contains the full path�names of valid login shells.
 

This module provides basic password authentification and session management. It is used my almost all services connected to the PAM subsystem.
 
Depended on the module-type flag this module serves different purposes. As account component (module type account) it performs the task of establishing the status of the user's account and password. In the case of the latter, it may offer advice to the user on changing their password or, through the PAM_AUTHTOKEN_REQD return, delay giving service to the user until they have established a new password.
 
When the module is called as authentication component (module-type auth), it verifies user name and password in the systems user database.
 
The third component of this module is the password mode (module-type password). In this mode it's function is to store the password in the systems user database.
 
Last but not least you can use tha module as session component (module-type session). Here its action is simply to log the username and the service-type to syslog(3). Messages are logged at the beginning and end of the user's session.
 
The following options are recognized:
 

This module logs information about the remote user and host (if pam-items are known).
 
This module is principally for logging information about a proposed authentication or application to update a password.
 
Log the service, terminal, user, remote user and remote host to syslog(3). The items are not probed for, but instead obtained from the standard pam-items.
 

In the previous sections you learned about the general syntax of the PAM configuration and about the function and syntax of the individual modules. Now it's time to look at some examples to see how the modules work togehter in order to guarante a secure system. Like said before, SuSE has individual configuration files for each service in the directory /etc/pam.d.
 

The most used service is the authentification of general user logins. Users have to identify themselfes to the login application. This utility asks for a user name and the referring password and then establishes a new session with the system.
 
The PAM settings for login is located in /etc/pam.d/login, which default configuration is shown here:
 

auth     requisite      /lib/security/pam_unix.so    nullok 
auth     required       /lib/security/pam_securetty.so 
auth     required       /lib/security/pam_nologin.so 
auth     required       /lib/security/pam_env.so 
auth     required       /lib/security/pam_mail.so 
account  required       /lib/security/pam_unix.so 
password required       /lib/security/pam_unix.so       strict=false 
session  required       /lib/security/pam_unix.so       none # debug or trace 
session  required       /lib/security/pam_limits.so 

This example shows that changing the password requires basically the same actions as logging into the system. First the user has to prove his identity, then the user database has to be checked if a password change is permitted (you may set the time to pass between password changes). If the password was changed, it has to be written to the user database and finally a log entry is made to note the password change.
 
Keeping this in mind it's not surprising to see the same instances of pam_unix.so in /etc/pam.d/passwd as we saw them ealier in the configuration for the login utility:
 

auth     required       /lib/security/pam_unix.so       nullok 
account  required       /lib/security/pam_unix.so 
password required       /lib/security/pam_unix.so       strict=false 
session  required       /lib/security/pam_unix.so 

The su allows one user to temporarily become another user. It runs a command (often an interactive shell) with the real and effective user ID, group ID, and supplemental groups of a given user.
 
In order to do this the other users password must be known and su prompts for the password before it executes the given command. This is the case fopr every user but root. The superuser can change identity without knowing the password.
 
For PAM this means that in case root calls su it should not prompt for a password, but if anybody else calls su a password has to be provided.
 
This is reflected by su's PAM configuration:
 

auth     sufficient     /lib/security/pam_rootok.so 
auth     required       /lib/security/pam_unix.so       nullok #set_secrpc 
account  required       /lib/security/pam_unix.so 
password required       /lib/security/pam_unix.so       #strict=false 
session  required       /lib/security/pam_unix.so       debug # trace or none