The Pluggable Authentication Module (PAM) framework allows for new authentication technologies to be plugged-in without changing your application commands such as web_auth, file_copy, or screen_save. It can be used to integrate an AIX login with other security mechanisms sich as DCE or Kerberos. Mechanisms for account, session, and password management can also be plugged in using this framework.
PAM allows the system administrator to choose any combination of services to provide authentication. The list below includes some of the advantages of PAM to the system administrator.
PAM employs run-time pluggable modules that provide authentication-related services. These modules are broken into four different categories: authentication, account management, session management, and password management.
PAM uses a concept called stacking to fully identify users through multiple authentication methods. Depending on the configuration, a user can be prompted for one or more passwords for each authentication method. The user does not need to remember to execute another command to get fully authenticated. The order in which methods are used is set in the/etc/pam.conf configuration file.
Stacking can require that a user must remember several passwords. However, if password mapping is supported by the underlying module, a primary password can be used to decrypt the other passwords, so the user only needs to remember the primary password. Alternatively, an administrator can synchronize the password across each authentication mechanism, but this method might increase the security risk because the security of each mechanism would be limited by the least secure password method used in the stack.
The following figure illustrates the relationship between the applications, the PAM library, and the PAM modules. The applications (web_auth, file_copy, and screen_save) use the PAM library to access the appropriate module. The pam.conf file defines which modules are used with each application. Responses from the modules are passed back through the library to the application.
Figure 3-2. PAM Framework and Entities. This illustration shows ficticious application commands using the PAM library to access the appropriate PAM module.
|
The PAM software consists of a library, several modules and a configuration file. The current release also includes new versions of several commands which use the PAM interfaces.
The PAM library, /usr/lib/libpam, provides the framework to load the appropriate modules and manage stacking. It provides a generic structure for all of the modules to plug into.
Each PAM module provides the implementation of a specific mechanism. More than one module type (authentication, account, session, or password) can be associated with each module, but each module needs to manage at least one module type. Here is a description of some of the modules.
Because the pam_unix module, /usr/lib/security/pam_unix.so.1, provides support for authentication, account management, session management, and password management, any module type definition can be used with this module. The pam_unix module uses AIX passwords for authentication.
The dial_auth module, /usr/lib/security/pam_dial_auth.so.1, can only be used for authentication. It uses data stored in the /etc/dialups and /etc/d_passwd files for authentication. This module is mainly used by the login command.
The rhosts_auth module, /usr/lib/security/pam_rhosts_auth.so.1, can also only be used for authentication. It uses data stored in the ~/.rhosts and /etc/host.equiv files through ruserok subroutine. Thismodule is mainly used by the rlogin and rsh command.
The pam_dce module, /usr/lib/security/pam_dce.so.1, provides support for authentication, account management, and password management. Any of these module type definitions can be used with this module. The module uses DCE registry for authentication.
For security reasons, these files must be owned by the root user and the permissions must be set so group or other cannot write to the files. If files are not owned by the root user, then PAM does not load the module.
The /etc/pam.conf configuration file can be edited to select authentication mechanisms for each system-entry application. The file consists of entries that use the following syntax:
service_name module_type control_flag module_path module_options
where:
The only optional component is module_options. The other values must be defined. Comments can be added to the file by starting a line with a pount sign (#). Whitespace delimits the fields.
An entry in this file is ignored if one of the following conditions exist:
One of three control_flags values must be selected for each entry to determine continuation or failure behavior from the module. These flags determine what the ultimate result (success or failure) will be. The values are defined below:
If all of the modules are flagged as required, then authentication through all modules must succeed for the user to be authenticated. If some of the modules fail, then a error value from the first failed module is reported. If a failure occurs for a required module, all modules in the stack are still tried but the access is denied.
If none of the modules are flagged as required, then at least one of the entries for that service must succeed for the user to be authenticated. The optional flag should be used when one success in the stack is enough. This flag should only be used when it is not important for this mechanism to succeed. For instance, if your users must have permission associated with a specific mechanism to get their work done, then that entry should not be flagged as optional.
The sufficient flag allows for one successful authentication to be enough for the user to get in.
The section below discusses some of the tasks that might be required for full PAM functionality. In particular, you should be note the security issues associated with each potential change to the configuration file.
When configuring PAM for your site, use the following general procedure:
Consider the following before changing the configuration file:
To disable reading the ~/.rhosts files during an rlogin session, remove the rlogin auth rhosts_auth.so.1 entry from the configuration file. This action prevents unauthenticated access to the local system from remote systems and requires a password for any rlogin access, regardless of the presence or contents of any ~/.rhosts or /etc/hosts.equiv files.
To prevent other non-authenticated access using the ~/.rhosts files remember to disable the rsh service. The best way to disable a particular service is to remove the service entry from the /etc/inetd.conf file. Making changes to the PAM configuration file does not prevent the service from starting.
To add the DEC PAM module, edit the /etc/pam.conf file to look like the following:
# # PAM configuration # # Authentication management # login auth sufficient /usr/lib/security/pam_dce.so.1 login auth required /usr/lib/security/pam_unix.so.1 rlogin auth required /usr/lib/security/pam_unix.so.1 rsh auth required /usr/lib/security/pam_rhost_auth.so.1 OTHER auth required /usr/lib/security/pam_unix.so.1 # # Account management # login account required /usr/lib/security/pam_dce.so.1 login account required /usr/lib/security/pam_unix.so.1 OTHER account required /usr/lib/security/pam_unix.so.1 # # Session management # OTHER session required /usr/lib/security/pam_unix.so.1 # # Password management # passwd password required /usr/lib/security/pam_dce.so.1 passwd password required /usr/lib/security/pam_unix.so.1
The sufficient flag on the login entry indicates that a user is authenticated if the pam_dce module suceeds, regardless of other modules, such as the pam_unix module. In this case, the pam_unix module is checked only when authentication through the pam_dce module fails.
The two entries for login authentication allow the root user to access the local system. This extra line is necessary because DCE does not grant root access by default. Because of these lines, non-root users without AIX password cannot get in, but a locally defined root account is able gain access.
The above example illustrates the DCE module's use only with the login command. However, the DCE module can be added for other services. If the pam_dce module is added as an auth module for login, it must also be added as an account module as well. The DCE entry for the passwd service ensures that the DCE password is also changed when the user runs the password command.
Note: If the PAM configuration file is misconfigured or becomes corrupted, it is possible that even the root user could not be able to login. The root user could use the su command, since it does not use PAM, then reboot the machine as a single-user machine to fix the /etc/pam.conf configuration file.
You must be logged in as the root user to edit the /etc/pam.conf file. Whenever you change the /etc/pam.conf file, and while you are still logged in as root, test each command that might be affected by your changes to ensure the configuration file remains valid. For example, if you add a new module to the telnet service, use the telnet command to test your changes and verify that the /etc/pam.conf file performs as expected.
Use the following procedure to add a PAM module:
Add entries to /etc/syslog.conf to initiate error reporting. The syslogd daemon must be restarted or a SIGHUP signal sent to it for any changes to take effect. The following selections can be added to the file to gather information about PAM:
The following entry prints all alert messages to the console. Critical messages are mailed to the root user. Informational and debug messages are added to /var/log/pamlog.
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 it, and a message. The /var/log/pamlog file can log a large amount of information.