This chapter covers the Pluggable Authentication Module (PAM) framework. PAM provides a method to “plug in” authentication services and provides support for multiple authentication services.
The Pluggable Authentication Module (PAM) framework lets you “plug in” new authentication technologies without changing system entry services, such as login, ftp, telnet, and so on. You can also use PAM to integrate UNIX login with other security mechanisms like DCE or Kerberos. Mechanisms for account, session, and password management can also be “plugged in” by using this framework.
The PAM framework allows you to choose any combination of system entry services (ftp, login, telnet, or rsh, for example) 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
Multiple passwords on high-security systems
Ease of use for the end user
No retyping of passwords if the passwords are the same for different mechanisms.
The ability to use a single password for multiple authentication methods with the password-mapping feature. This feature works even if the passwords that are associated with each authentication method are different.
The ability to prompt the user for passwords for multiple authentication methods without having the user enter multiple commands.
The ability to pass optional parameters to the user authentication services
The PAM software consists of a library, several modules, and a configuration file. New versions of several commands or daemons that take advantage of the PAM interfaces are also included.
The following figure illustrates the relationship between the applications, the PAM library, the pam.conf file, and the PAM modules.
The applications, such as ftp, telnet, and login, use the PAM library to access the appropriate module. The pam.conf file defines which modules to use, and in what order the modules are to be used with each application. Responses from the modules are passed back through the library to the application.
The following sections describe the relationship between the PAM components and the applications.
The PAM library, /usr/lib/libpam, provides the framework to load the appropriate modules and to manage the stacking process. The PAM library provides a generic structure to which all of the modules can plug in.
The PAM framework provides a method for authenticating users with multiple services by using stacking. Depending on the configuration, the user can be prompted for passwords for each authentication method. The order in which the authentication services are used is determined through the PAM configuration file.
The stacking feature can require that a user remembers several passwords. With the password-mapping feature, the primary password is used to decrypt the other passwords. The user does not need to remember or enter multiple passwords. The other option is to synchronize the passwords across each authentication mechanism. This strategy could increase the security risk, because the mechanism security is limited by the least secure password method that is used in the stack.
The Solaris 9 release includes several enhancements to the PAM service. The following list highlights the most important changes:
To accommodate proper stacking, the pam_unix module is broken into single service modules. These modules provide the same capabilities as in the existing module. The capabilities are provided by the following modules:
pam_authtok_get
pam_authtok_check
pam_authtok_store
pam_unix_auth
pam_dhkeys
pam_passwd_auth
See PAM Modules for information about the new modules.
New PAM services are included: cron, dtsession, ppp and ssh. See Valid Service Names for PAM for information about the new services.
The PAM configuration file was updated to include the new modules and new services. See Generic pam.conf File for information about the configuration file.
Update 2 includes a new binding control flag. This flag provides the ability to skip additional authentication if the service module returns success and if no preceding required modules have failed. The control flag is documented in the pam.conf(4) man page and in PAM Control Flags.
This section discusses some tasks that might be required to make the PAM framework fully functional. In particular, you should be aware of some security issues that are associated with the PAM configuration file.
Task |
Description |
For Instructions |
---|---|---|
Plan for your PAM Installation | Consider configuration issues and make decisions about them before you start the software configuration process. | Planning for PAM |
Add new PAM modules | Sometimes, site-specific modules must be written and installed to cover requirements that are not part of the generic software. This procedure covers the installation process. | How to Add a PAM Module |
Block access through ~/.rhosts | Steps to further increase security by preventing access through ~/.rhosts. | How to Prevent Unauthorized Access From Remote Systems With PAM |
Initiate error reporting | Steps to start the reporting of PAM error messages through syslog. | How to Initiate PAM Error Reporting |
When you are deciding how best to use PAM in your environment, start by focusing on these issues:
Determine what your needs are, especially which modules you should select.
Identify the services that need special attention. Use OTHER if appropriate.
Decide on the order in which the modules should be run.
Select the control flag for each module.
Choose any options that are necessary for each module.
Here are some suggestions to consider before you change the PAM configuration file:
Use the OTHER entry for each module type so that every application does not have to be included.
Make sure to consider the security implications of the 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.
If the PAM configuration file is misconfigured or the file becomes corrupted, even superuser might be unable to log in. Since the sulogin command does not use PAM, superuser 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 are still logged in as superuser. 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 use the telnet command and verify that your changes make the service behave as expected.
Become superuser or assume an equivalent role.
Determine which control flags and which other options should be used.
Refer to PAM Modules information on the modules.
Copy the new module to /usr/lib/security/sparcv9.
In the Solaris 8 release, the module should be copied to /usr/lib/security.
Set the permissions so that the module file is owned by root and that permissions are 555.
Edit the PAM configuration file, /etc/pam.conf, and add this module to the appropriate services.
You must test before the system is rebooted in case the configuration file is misconfigured. Run rlogin, su, and telnet 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.
Remove the rlogin auth rhosts_auth.so.1 entry 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.
To prevent other unauthenticated access to the ~/.rhosts files, remember to disable the rsh service. The best way to disable a service is to remove the service entry from the /etc/inetd.conf file. Changing the PAM configuration file does not prevent the service from being started.
Edit the /etc/syslog.conf file to add any of the following entries for PAM error reporting:
auth.alert – Messages about conditions that should be fixed immediately
auth.crit – Critical messages
auth.err – Error messages
auth.info – Informational messages
auth.debug – Debugging messages
Restart the syslog daemon, or send a SIGHUP signal to the daemon to activate the PAM error reporting.
In the following example, all alert messages are displayed on the console. Critical messages are mailed to root. Informational and debug messages are added to the /var/log/pamlog file.
auth.alert /dev/console auth.crit 'root' auth.info;auth.debug /var/log/pamlog |
Each line in the log contains a time stamp, the name of the system that generated the message, and the message. The pamlog file is capable of logging a large amount of information.
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.
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.
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.
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.
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.
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.
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 |
---|---|---|
/usr/sbin/cron |
auth, account |
|
/usr/dt/bin/dtlogin |
auth, account, session |
|
/usr/dt/bin/dtsession |
auth |
|
/usr/sbin/in.ftpd |
auth, account, session |
|
/usr/sbin/init |
session |
|
/usr/bin/login |
auth, account, session |
|
/usr/bin/passwd |
password |
|
/usr/bin/ppp |
auth, account, session |
|
/usr/sbin/rpc.rexd |
account, session |
|
/usr/sbin/in.rlogind |
auth, account, session |
|
/usr/sbin/in.rshd |
auth, account, session |
|
/usr/lib/saf/sac |
session |
|
/usr/bin/ssh |
auth, account, session |
|
/usr/bin/su |
auth, account |
|
/usr/sbin/in.telnetd |
auth, account, session |
|
/usr/lib/saf/ttymon |
session |
|
/usr/sbin/in.uucpd |
auth, account, session |
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.
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.