Chapter 17 Using PAM

This chapter covers the Pluggable Authentication Module (PAM) framework. PAM provides a method to “plug in” authentication services into the Solaris Operating System (Solaris OS). PAM provides support for multiple authentication services when accessing a system.

• PAM (Overview)

• PAM (Tasks)

• PAM Configuration (Reference)

PAM (Overview)

The Pluggable Authentication Module (PAM) framework lets you “plug in” new authentication services without changing system entry services, such as login, ftp, and telnet. You can also use PAM to integrate UNIX login with other security mechanisms such as Kerberos. Mechanisms for account, credential, session, and password management can also be “plugged in” by using this framework.

Benefits of Using PAM

The PAM framework enables you to configure the use of system entry services (such as, ftp, login, telnet, or rsh) for user authentication. Some benefits that PAM provides are as follows:

• Flexible configuration policy

  • Per-application authentication policy

  • The ability to choose a default authentication mechanism

  • The ability to require multiple authorizations on high-security systems

• Ease of use for the end user

  • No retyping of passwords if the passwords are the same for different authentication services

  • The ability to prompt the user for passwords for multiple authentication services without requiring the user to type multiple commands

• The ability to pass optional options to the user authentication services

• The ability to implement a site-specific security policy without having to change the system entry services

Introduction to the PAM Framework

The PAM framework consists of four parts:

• PAM consumers

• PAM library

• The pam.conf(4) configuration file

• PAM service modules, also referred to as providers

The framework provides a uniform way for authentication-related activities to take place. This approach enables application developers to use PAM services without having to know the semantics of the policy. Algorithms are centrally supplied. The algorithms can be modified independently of the individual applications. With PAM, administrators can tailor the authentication process to the needs of a particular system without having to change any applications. Adjustments are made through pam.conf, the PAM configuration file.

The following figure illustrates the PAM architecture. Applications communicate with the PAM library through the PAM application programming interface (API). PAM modules communicate with the PAM library through the PAM service provider interface (SPI). Thus, the PAM library enables applications and modules to communicate with each other.

Figure 17–1 PAM Architecture

Changes to PAM for the Solaris 10 Release

The Solaris 10 release includes the following changes to the Pluggable Authentication Module (PAM) framework:

• The pam_authtok_check module now allows for strict password checking using new tunable parameters in the /etc/default/passwd file. The new parameters define:

  • A list of comma separated dictionary files used for checking common dictionary words in a password

  • The minimum differences required between a new password and an old password

  • The minimum number of alphabetic or nonalphabetic characters that must be used in a new password

  • The minimum number of uppercase or lowercase letters that must be used in a new password

  • The number of allowable consecutive repeating characters

• The pam_unix_auth module implements account locking for local users. Account locking is enabled by the LOCK_AFTER_RETRIES parameter in /etc/security/policy.conf and the lock_after-retries key in /etc/user_attr. See the policy.conf(4) and the user_attr(4) man pages for more information.

• A new binding control flag has been defined. This control flag is documented in the pam.conf(4) man page and in How PAM Stacking Works.

• The pam_unix module has been removed and replaced by a set of service modules of equivalent or greater functionality. Many of these modules were introduced in the Solaris 9 release. Here is a list of the replacement modules:

  • pam_authtok_check

  • pam_authtok_get

  • pam_authtok_store

  • pam_dhkeys

  • pam_passwd_auth

  • pam_unix_account

  • pam_unix_auth

  • pam_unix_cred

  • pam_unix_session

• The functionality of the pam_unix_auth module has been split into two modules. The pam_unix_auth module now verifies that the password is correct for the user. The new pam_unix_cred module provides functions that establish user credential information.

• Additions to the pam_krb5 module have been made to manage the Kerberos credentials cache using the PAM framework.

• A new pam_deny module has been added. The module can be used to deny access to services. By default, the pam_deny module is not used. For more information, see the pam_deny(5) man page.

Changes to PAM for the Solaris Express 1/06 Release

The PAM framework for the Solaris Express 1/06 release includes a new pam_allow module. The module can be used to grant access to all users, without enforcing any security. The module should be used with caution. For more information, see the pam_allow(5) man page.

PAM (Tasks)

This section discusses some tasks that might be required to make the PAM framework use a particular security policy. You should be aware of some security issues that are associated with the PAM configuration file. For information about the security issues, see Planning for Your PAM Implementation.

PAM (Task Map)

Planning for Your PAM Implementation

As delivered, the pam.conf configuration file implements the standard Solaris security policy. This policy should work in many situations. If you need to implement a different security policy, here are the issues that you should focus on:

• Determine what your needs are, especially which PAM service modules you should select.

• Identify the services that need special configuration options. Use other if appropriate.

• Decide the order in which the modules should be run.

• Select the control flag for each module. See How PAM Stacking Works for more information about all of the control flags.

• Choose any options that are necessary for each module. The man page for each module should list any special options.

Here are some suggestions to consider before you change the PAM configuration file:

• Use other entries for each module type so that every application does not have to be included in /etc/pam.conf.

• Make sure to consider the security implications of the binding, sufficient, and optional control flags.

• Review the man pages that are associated with the modules. These man pages can help you understand how each module functions, what options are available, and the interactions between stacked modules.

  ---

  Caution –

  If the PAM configuration file is misconfigured or the file becomes corrupted, no user might be able to log in. Because the sulogin command does not use PAM, the root password would then be required to boot the machine into single-user mode and fix the problem.

  ---

  After you change the /etc/pam.conf file, review the file as much as possible while you still have system access to correct problems. Test all the commands that might have been affected by your changes. An example is adding a new module to the telnet service. In this example, you would use the telnet command and verify that your changes make the service behave as expected.

How to Add a PAM Module

This procedure shows how to add a new PAM module. New modules can be created to cover site-specific security policies or to support third party applications.

1. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map).

2. Determine which control flags and which other options should be used.

   Refer to How PAM Stacking Works for information on the control flags.

3. Ensure that the ownership and permissions are set so that the module file is owned by root and the permissions are 555.

4. Edit the PAM configuration file, /etc/pam.conf, and add this module to the appropriate services.

5. Verify that the module has been added properly.

   You must test before the system is rebooted in case the configuration file is misconfigured. Login using a direct service, such as ssh, and run the su command, before you reboot the system. The service might be a daemon that is spawned only once when the system is booted. Then, you must reboot the system before you can verify that the module has been added.

How to Prevent Rhost-Style Access From Remote Systems With PAM

1. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map).

2. Remove all of the lines that include rhosts_auth.so.1 from the PAM configuration file.

   This step prevents the reading of the ~/.rhosts files during an rlogin session. Therefore, this step prevents unauthenticated access to the local system from remote systems. All rlogin access requires a password, regardless of the presence or contents of any ~/.rhosts or /etc/hosts.equiv files.

3. Disable the rsh service.

   To prevent other unauthenticated access to the ~/.rhosts files, remember to disable the rsh service.

   # svcadm disable network/shell

How to Log PAM Error Reports

1. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map).

2. Configure the /etc/syslog.conf file for the level of logging that you need.

   See the syslog.conf(4) for more information about the logging levels.

3. Refresh the configuration information for the syslog daemon.

   # svcadm refresh system/system-log

PAM Configuration (Reference)

The PAM configuration file, pam.conf(4), is used to configure PAM service modules for system services, such as login, rlogin, su, and cron. The system administrator manages this file. An incorrect order of entries in pam.conf can cause unforeseen side effects. For example, a badly configured pam.conf can lock out users so that single-user mode becomes necessary for repair. For a description of setting the order, see How PAM Stacking Works.

PAM Configuration File Syntax

The entries in the configuration file are in the format:

service-name module-type control-flag module-path module-options

service-name

Name of the service, for example, ftp, login, or passwd. An application can use different service names for the services that the application provides. For example, the Solaris secure shell daemon uses these service names: sshd-none, sshd-password, sshd-kbdint, sshd-pubkey, and sshd-hostbased. The service-name other is a predefined name that is used as a wildcard service-name. If a particular service-name is not found in the configuration file, the configuration for other is used.

module-type

The type of service, that is, auth, account, session, or password.

control-flag

Indicates the role of the module in determining the integrated success or failure value for the service. Valid control flags are binding, include, optional, required, requisite, and sufficient. See How PAM Stacking Works for information on the use of these flags.

module-path

The path to the library object that implements the service. If the pathname is not absolute, the pathname is assumed to be relative to /usr/lib/security/$ISA/. Use the architecture-dependent macro $ISA to cause libpam to look in the directory for the particular architecture of the application.

module-options

Options that are passed to the service modules. A module's man page describes the options that are accepted by that module. Typical module options include nowarn and debug.

How PAM Stacking Works

When an application calls on the following functions, libpam reads the configuration file /etc/pam.conf to determine which modules participate in the operation for this service:

• pam_authenticate(3PAM)

• pam_acct_mgmt(3PAM)

• pam_setcred(3PAM)

• pam_open_session(3PAM)

• pam_close_session(3PAM)

• pam_chauthtok(3PAM)

If /etc/pam.conf contains only one module for an operation for this service such as authentication or account management, the result of that module determines the outcome of the operation. For example, the default authentication operation for the passwd application contains one module, pam_passwd_auth.so.1:

passwd  auth required           pam_passwd_auth.so.1

If, on the other hand, there are multiple modules defined for the service's operation, those modules are said to be stacked and that a PAM stack exists for that service. For example, consider the case where pam.conf contains the following entries:

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

These entries represent a sample auth stack for the login service. To determine the outcome of this stack, the result codes of the individual modules require an integration process. In the integration process, the modules are executed in order as specified in /etc/pam.conf. Each success or failure code is integrated in the overall result depending on the module's control flag. The control flag can cause early termination of the stack. For example, a requisite module might fail, or a sufficient or binding module might succeed. After the stack has been processed, the individual results are combined into a single, overall result that is delivered to the application.

The control flag indicates the role that a PAM module plays in determining access to the service. The control flags and their effects are:

• Binding – Success in meeting a binding module's requirements returns success immediately to the application if no previous required modules have failed. If these conditions are met, then no further execution of modules occurs. Failure causes a required failure to be recorded and the processing of modules to be continued.

• Include – Adds lines from a separate PAM configuration file to be used at this point in the PAM stack. This flag does not control success or failure behaviors. When a new file is read, the PAM include stack is incremented. When the stack check in the new file finishes, the include stack value is decremented. When the end of a file is reached and the PAM include stack is 0, then the stack processing ends. The maximum number for the PAM include stack is 32.

• Optional – Success in meeting an optional module's requirements is not necessary for using the service. Failure causes an optional failure to be recorded.

• Required – Success in meeting a required module's requirements is necessary for using the service. Failure results in an error return after the remaining modules for this service have been executed. Final success for the service is returned only if no binding or required modules have reported failures.

• Requisite – Success in meeting a requisite module's requirements is necessary for using the service. Failure results in an immediate error return with no further execution of modules. All requisite modules for a service must return success for the function to be able to return success to the application.

• Sufficient – If no previous required failures have occurred, success in a sufficient module returns success to the application immediately with no further execution of modules. Failure causes an optional failure to be recorded.

The following two diagrams shows how access is determined in the integration process. The first diagram indicates how success or failure is recorded for each type of control flag. The second diagram shows how the integrated value is determined.

Figure 17–2 PAM Stacking: Effect of Control Flags

Figure 17–3 PAM Stacking: How Integrated Value Is Determined

PAM Stacking Example

Consider the following example of an rlogin service that requests authentication.

Example 17–1 Partial Contents of a Typical PAM Configuration File

The pam.conf file in this example has the following contents for rlogin services:

     # Authentication management
     ...     
     # rlogin service 
     rlogin  auth sufficient         pam_rhosts_auth.so.1
     rlogin  auth requisite          pam_authtok_get.so.1
     rlogin  auth required           pam_dhkeys.so.1
     rlogin  auth required           pam_unix_auth.so.1
     ...

When the rlogin service requests authentication, libpam first executes the pam_rhosts_auth(5) module. The control flag is set to sufficient for the pam_rhosts_auth module. If the pam_rhosts_auth module is able to authenticate the user, then processing stops and success is returned to the application.

If the pam_rhosts_auth module fails to authenticate the user, then the next PAM module, pam_authtok_get(5) is executed. The control flag for this module is set to requisite. If pam_authtok_get fails, then the authentication process ends and the failure is returned to rlogin.

If pam_authtok_get succeeds, then the next two modules, pam_dhkeys(5) and pam_unix_auth(5), are executed. Both modules have the associated control flags that are set to required so that the process continues regardless of whether an individual failure is returned. After pam_unix_auth is executed, no modules for rlogin authentication remain. At this point, if either pam_dhkeys or pam_unix_auth has returned a failure, the user is denied access through rlogin.