System Administration Guide: Security Services

PAM (Reference)

PAM uses run-time pluggable modules to provide authentication for system entry services. A stacking feature is provided to let you authenticate users through multiple services. Also provided is a password-mapping feature to not require that users remember multiple passwords.

PAM Modules

Every PAM module implements a specific mechanism. When you set up PAM authentication, you need to specify both the module and the module type, which defines what the module does. More than one module type, such as auth, account, session, or password, can be associated with each module.

The following table describes every PAM module, and includes the module name and the module file name. The path of each module is determined by the instruction set that is available in the Solaris release that is installed. The default path to the modules is /usr/lib/security/$ISA. The value for $ISA could be sparc or i386. See the isalist(5) man page for more information.

Table 4–1 PAM Modules


Module Name and Module File Name	Description
`authtok_check` `pam_authtok_check.so.1`	Provides support for password management. This module performs various checks on passwords. Those check are for the length of the password, for circular shift of the login name, for password complexity, and for the amount of variation between new passwords and old passwords. See pam_authtok_check(5) for more information.
`authtok_get` `pam_authtok_get.so.1`	Provides password prompting for authentication and password management. See pam_authtok_get(5) for more information.
`authtok_store` `pam_authtok_store.so.1`	Provides support for authentication only. This module updates the authentication token for the user. After the successful update, the module stores the token in the specified repository or default repository. See pam_authtok_store(5) for more information.
`dhkeys` `pam_dhkeys.so.1`	Provides support for Diffie-Hellman key management in authentication. This module supports Secure RPC authentication and Secure RPC authentication token management. See pam_dhkeys(5) for more information.
`dial_auth` `pam_dial_auth.so.1`	Can only be used for authentication. This module uses data that is stored in the `/etc/dialups` and `/etc/d_passwd` files for authentication. This module is mainly used by the `login` command. See pam_dial_auth(5) for more information.
`krb5` `pam_krb5_auth.so.1`	Provides support for authentication, account management, session management, and password management. Kerberos credentials are used for authentication. See pam_krb5(5) for more information.
`ldap` `pam_ldap.so.1`	Provides support for authentication and password management. Data from an LDAP server are used for authentication. See pam_ldap(5) for more information.
`projects` `pam_projects.so.1`	Provides support for account management. See pam_projects(5) for more information.
`rhosts_auth` `pam_rhosts_auth.so.1`	Can only be used for authentication. This module uses data that is stored in the `~/.rhosts` and `/etc/host.equiv` files through the `ruserok()` routine. This module is mainly used by the `rlogin` and `rsh` commands. See pam_rhosts_auth(5) for more information.
`roles` `pam_roles.so.1`	Provides support for account management only. The RBAC `user_attr` database determines which roles a user can assume. See pam_roles(5) for more information.
`sample` `pam_sample.so.1`	Provides support for authentication, account management, session management, and password management. Used for testing. See pam_sample(5) for more information.
`smartcard` `pam_smartcard.so.1`	Provides support for authentication only. See pam_smartcard(5) for more information.
`unix` `pam_unix.so.1`	Provides support for authentication, account management, session management, and password management. Any of the four module type definitions can be used with this module. This module uses UNIX passwords for authentication. In the Solaris environment, the selection of appropriate name services to get password records is controlled through the `/etc/nsswitch.conf` file. See pam_unix(5) for more information.
`unix_account` `pam_unix_account.so.1`	Provides support for account management. This module retrieves password aging information from the repository that is specified in the `nsswitch.conf` file. Then the module verifies that the password and the user's account have not expired. See pam_unix_account(5) for more information.
`unix_auth` `pam_unix_auth.so.1`	Provides support for authentication. This module verifies the password that is contained in the PAM handle. The module checks that the user's password matches the password in the specified repository or default repository. See pam_unix_auth(5) for more information.
`unix_session` `pam_unix_session.so.1`	Provides support for session management. This module initiates session management by updating the `/var/adm/lastlog` file. See pam_unix_session(5) for more information.

For security reasons, these module files must be owned by root and must not be writable through group or other permissions. If the file is not owned by root, PAM does not load the module.

PAM Module Types

You need to understand the PAM module types because the types define the interface to the module. Here are the four types of run-time PAM modules:

The authentication modules provide authentication for the users. The modules also allow for credentials to be set, refreshed, or destroyed. In addition, the modules provide a valuable administration tool for user identification.
The account modules check for password aging, account expiration, and access hour restrictions. After the user is identified through the authentication modules, the account modules determine if the user should be given access.
The session modules manage the opening and the closing of an authentication session. These modules also can log activity or provide for cleanup after the session is over.
The password modules allow for changes to the actual password.

PAM Configuration File

The PAM configuration file, /etc/pam.conf, determines the authentication services to be used, and the order in which the services are used. This file can be edited to select authentication mechanisms for each system entry application.

PAM Configuration File Syntax

The PAM configuration file consists of entries with the following syntax:

service_name module_type control_flag module_path module_options

`service_name`	Is the name of the service, for example, `ftp`, `login`, `telnet`.
`module_type`	Is the module type for the service. For more information, see PAM Module Types.
`control_flag`	Determines the continuation or failure behavior for the module.
`module_path`	Specifies the path to the library object that implements the service.
`module_options`	Specifies the options that are passed to the service modules.

You can add comments to the pam.conf file by starting the line with a # (pound sign). Use white spaces or tabs to delimit the fields.

Note –

An entry in the PAM configuration file is ignored if one of the following conditions exists: the line has less than four fields, an invalid value is given for module_type or control_flag, or the named module does not exist.

Valid Service Names for PAM

The following table lists:

The valid service names
The module types that can be used with that service
The daemon or command that is associated with the service name

Some module types are not appropriate for each service. For example, the password module type is appropriate for only the passwd command. Also, because the passwd command is not concerned with authentication, no auth module type is associated with the service.

Table 4–2 Valid Service Names for the /etc/pam.conf File


Service Name	Daemon or Command	Applicable Module Types
`cron`	`/usr/sbin/cron`	`auth, account`
`dtlogin`	`/usr/dt/bin/dtlogin`	`auth, account, session`
`dtsession`	`/usr/dt/bin/dtsession`	`auth`
`ftp`	`/usr/sbin/in.ftpd`	`auth, account, session`
`init`	`/usr/sbin/init`	`session`
`login`	`/usr/bin/login`	`auth, account, session`
`passwd`	`/usr/bin/passwd`	`password`
`ppp`	`/usr/bin/ppp`	`auth, account, session`
`rexd`	`/usr/sbin/rpc.rexd`	`account, session`
`rlogin`	`/usr/sbin/in.rlogind`	`auth, account, session`
`rsh`	`/usr/sbin/in.rshd`	`auth, account, session`
`sac`	`/usr/lib/saf/sac`	`session`
`ssh`	`/usr/bin/ssh`	`auth, account, session`
`su`	`/usr/bin/su`	`auth, account`
`telnet`	`/usr/sbin/in.telnetd`	`auth, account, session`
`ttymon`	`/usr/lib/saf/ttymon`	`session`
`uucp`	`/usr/sbin/in.uucpd`	`auth, account, session`

PAM Control Flags

To determine the continuation or failure behavior from a module, you must select a control flag for each entry in the PAM configuration file, /etc/pam.conf. Each module in a stack can determine the success or failure of the request.

Continuation behavior defines if any following modules are checked. Depending on the response from a particular module, you can decide to skip any additional modules.

Failure behavior defines how error messages are logged or reported. Failures are either optional or required. A required failure causes that request to fail, even if other modules succeed. An optional failure does not always cause the request to fail.

Even though these flags apply to all module types, the following explanation assumes that these flags are being used for authentication modules. The control flags are as follows:

binding – With this control flag, if the module is successful and no preceding modules that are flagged as required have failed, then skip the remaining modules. If a failure is returned, record a required failure and continue processing the stack.

The binding control flag is like the required control flag, except that no additional module checking is done if the module is successful. A failure using this flag prevents the request from being successful, regardless of the response of any other modules. A success using this flag makes the request successful if no preceding required modules failed.
required – With this control flag, if the module is successful, record a required success and continue checking any following modules. If the module fails, and if this is the first required failure, save the error message and continue checking the stack. If this is not the first failure, then continue checking the stack.

The required control flag should be used when a particular module must succeed for the request to be successful. A failure when using this flag prevents the request from being successful, regardless of the response of any other modules. A success when using this flag does not mean that the request is successful. All of the responses from the other required modules in the stack must be successful for the request to succeed.
requisite – With this control flag, if the module is successful, record a required success and continue checking any following modules. If the module fails, record a required failure, return the error message of the first required failure, and skip any additional checking.

The requisite control flag is like the required control flag, except that no additional module checking is done if the module fails. A failure when using this flag prevents the request from being successful, regardless of the response of any other modules. A success when using this flag does not mean that the request is successful. All of the responses from the other required modules in the stack must be successful for the request to succeed.
optional – With this control flag, if the module is successful, record an optional success and continue checking the stack. If the module fails, record an optional failure and continue checking the stack.

The optional control flag should be used when successful authentication in the stack is enough for a user to be authenticated. This flag should only be used if this particular mechanism does not need to succeed. The success or failure of the request, is determined by any required failures or successes.

If your users need to have permission associated with a specific mechanism to get their work done, then you should not label the module as optional.
sufficient – With this control flag, if the module is successful, and no preceding modules that are flagged as required have failed, then skip the remaining modules. If the module fails, record an option failure and continue checking the stack.

The sufficient control flag is like the optional control flag, except that no additional module checking is done if the module succeeds. A success when using this flag makes the request successful if no preceding required modules failed. A failure when using this flag causes the request to fail if no other modules succeeded.

More information about these control flags is provided in the following section, which describes the default /etc/pam.conf file.

Generic `pam.conf` File

The generic /etc/pam.conf file specifies the following actions:

When the login command is run, authentication must succeed for the pam_authtok_get, pam_dhkeys, pam_auth_unix, and the pam_dial_auth modules.
For the rlogin command, authentication through the pam_authtok_get, pam_dhkeys, and pam_auth_unix modules must succeed if authentication through pam_rhost_auth fails.
The sufficient control flag indicates that for the rlogin command, the successful authentication that is provided by the pam_rhost_auth module is sufficient. The next entry is ignored.
Most of the other commands that require authentication require successful authentication through the pam_authtok_get, pam_dhkeys, and pam_auth_unix modules.
For the rsh command, authentication through the pam_rhost_auth module is flagged as sufficient. No other authentication is required if authentication through the pam_rhost_auth module succeeds.

The OTHER service name allows a default to be set for any other commands that require authentication and are not included in the file. The OTHER option simplifies administration of the file, since many commands that are using the same module can be covered by using only one entry. Also, the OTHER service name, when used as a “catch-all,” can ensure that each access is covered by one module. By convention, the OTHER entry is included at the bottom of the section for each module type.

Normally, the entry for the module_path is “root-relative.” If the file name that you enter for module_path does not begin with a slash (/), the path /usr/lib/security/$ISA precedes the file name. A full path name must be used for modules that are located in other directories. The values for the module_options can be found in the man pages for the module. For example, the UNIX module is covered in the pam_unix(5) man page.

login   auth required           pam_authtok_get.so.1
login   auth required           pam_dhkeys.so.1
login   auth required           pam_unix_auth.so.1
login   auth required           pam_dial_auth.so.1

In this example, the login service specifies authentication through all four authentication modules. A login command fails if any one of the modules returns an error.