Linux Security and PAM
PAM (Pluggable Authentication Modules) provides a layer between applications and the actual authentification mechanism. PAM is a library of loadable modules called by applications which are used for security requirements in each application. They enable the local system administrator to choose how applications authenticate users. They also allow the system administrator to control when a user can login and many other customize able features. PAM is also useful so the authentification method can be modified without changing the application. For instance current logins may be done by checking a password file. You may want to modify it to use a "smart" card instead. All that is necessary is to change the PAM libraries that the application uses to do the authentification rather than re-writing the application. There are four types of modules:
- auth - Provide the actual authentication to tell who the user is and if they are who they say they are, possibly asking a password then checking it, and setting credentials like as group memberships or kerberos tickets.
- account - Check to see if the authentication is allowed. It may restrict access based on currently available system resources such as the maximum number of users or the location of the user. Access could be denied if the account has expired or the user is not allowed to log in at this time of day.
- password - Used to set passwords. Typically, there is one module for each auth module-type
- session - Used to make it possible for a user to use their account once they have been authenticated. This module does things that need to be done for the user before or after they can be given service such as logging of information concerning the opening or closing of some data exchange with a user, or mounting directories. This module may make the user's mailbox available.
All PAM applications are configured in the directory "/etc/pam.d" or in a file "/etc/pam.conf". PAM is controlled using the configuration file or the configuration directory, but usually not both. If both configurations are used the directory structure takes precedence. In the directory "/etc/pam.d" there is a file for each application. Each application is tied to a set of PAM libraries with a file named after the name of the service in the "/etc/pam.d" directory. In the "/etc/pam.conf" file the first value on each line is the service name. The service name is the name of the program used to access the service, not the program used to provide the service. My "/etc/pam.d/rlogin" file looks like this:
#%PAM-1.0
auth required /lib/security/pam_securetty.so
auth required /lib/security/pam_pwdb.so shadow nullok
auth required /lib/security/pam_nologin.so
account required /lib/security/pam_pwdb.so
password required /lib/security/pam_cracklib.so
password required /lib/security/pam_pwdb.so nullok use_authtok md5 shadow
session required /lib/security/pam_pwdb.so
session optional /lib/security/pam_console.so
|
|
A general configuration line of the /etc/pam.conf file has the following form:
service-name module-type control-flag module-path arguments
The service name indicates the type of service such as ftp and is not required for configuration files in the directory "/etc/pam.d".
As you can see multiple modules may be used and multiple modules of each type may be used. The second item is the module type(listed above), the third item is the control flag, and the fourth is the loadable library to be used to perform the function. The control flags are:
- required - The success of the module is required for the module-type facility to succeed. Failure of this module will not be apparent to the user until all of the remaining modules (of the same module-type) have been executed.
- requisite - If the module returns a failure, control is directly returned to the application. The return value is that associated with the first required or requisite module to fail. This flag can be used to protect against the possibility of a user getting the opportunity to enter a password over an unsafe medium.
- sufficient - If this module succeeds and no previous required module has failed, no more `stacked' modules of this type are invoked. This means subsequent required modules are not invoked. A failure of this module is not deemed as fatal to satisfying the application that this module-type has succeeded.
- optional - This module is not critical to the success or failure of the user's application for service. In the absence of any definite successes or failures of previous or subsequent stacked modules this module will determine the nature of the response to the application.
The newer syntax for control flags is is delimited with square brackets and consists of a series of value=action tokens with the value being set to one of the following return values The format of the syntax is:
[value1=action1 value2=action2 ...]
The values are:
- success
- open_err
- symbol_err
- service_err
- system_err
- buf_err
- perm_denied
- auth_err
- cred_insufficient
- authinfo_unavail
- user_unknown
- maxtries
- new_authtok_reqd
- acct_expired
- session_err
- cred_unavail
- cred_expired
- cred_err
- no_module_data
- conv_err
- authtok_err
- authtok_recover_err
- authtok_lock_busy
- authtok_disable_aging
- try_again; ignore
- abort
- authtok_expired
- module_unknown
- bad_item
- default - Can be used to set the action for those return values that are not explicitly defined.
The action can be a positive integer or one of the tokens listed below. A positive integer, J, when specified as the action, can be used to indicate that the next J modules of the current type will be skipped. In this way, the administrator can develop a moderately sophisticated stack of modules with a number of different paths of execution. Which path is taken can be determined by the reactions of individual modules.
- ignore - when used with a stack of modules, the module's return status will not contribute to the return code the application obtains.
- bad - this action indicates that the return code should be thought of as indicative of the module failing. If this module is the first in the stack to fail, its status value will be used for that of the whole stack.
- die - equivalent to bad with the side effect of terminating the module stack and PAM immediately returning to the application.
- ok - this tells PAM that the administrator thinks this return code should contribute directly to the return code of the full stack of modules. In other words, if the former state of the stack would lead to a return of PAM_SUCCESS, the module's return code will override this value. Note, if the former state of the stack holds some value that is indicative of a modules failure, this 'ok' value will not be used to override that value.
- done - equivalent to ok with the side effect of terminating the module stack and PAM immediately returning to the application.
- reset - clear all memory of the state of the module stack and start again with the next stacked module.
The module path is the path and file name of the PAM library to be used to perform the function.
The args are like arguments to a typical Linux shell command. Valid arguments are optional and are specific to specific modules.
Listing of available PAM modules
Some PAM files
- /etc/securetty/pam.conf
- /etc/security/access.conf
- /etc/security/group.conf
- /etc/security/limits.conf
- /etc/security/pam-env.conf
- /etc/security/time.conf
- /etc/pam.d/other
- /usr/lib/libpam.so.* - The shared library providing applications with access to Linux-PAM.
- /etc/pam.conf - The Linux-PAM configuration file.
- /usr/lib/security/pam_*.so - The primary location for Linux-PAM dynamically loadable object files; the modules.
|