Linux Pluggable authentication Module (PAM) configuration file, working principle and process

Pam's configuration file:

We note that the configuration file is also placed in the application interface layer, which is used in conjunction with the PAM API to achieve the flexibility of inserting the required authentication module in the application. His main role is to select specific identification modules for the application, the combination of modules and the behavior of the specified modules. Here is a sample configuration file:

# cat/etc/pam.d/system-auth:#%pam-1.0# This file is auto-generated.# User changes'll be destroyed the next time Authcon Fig is Run.auth        required      /lib/security/$ISA/pam_env.soauth        sufficient    /lib/security/$ISA/PAM_ unix.so Likeauth Nullokauth        required      /lib/security/$ISA/pam_deny.soaccount     required      /lib/ security/$ISA/pam_unix.soaccount     sufficient    /lib/security/$ISA/pam_succeed_if.so uid < Quietaccount     Required      /lib/security/$ISA/pam_permit.sopassword    requisite     /lib/security/$ISA/PAM_ cracklib.so Retry=3password    sufficient    /lib/security/$ISA/pam_unix.so Nullok use_authtok MD5 Shadow Nispassword    required      /lib/security/$ISA/pam_deny.sosession     required/lib/security/      $ISA/pam _limits.sosession     required      /lib/security/$ISA/pam_unix.so

As we can see, the configuration file consists of a number of configuration items (one for each configuration item), and each row is divided into four columns (one column for each row):

first column, authentication identification interface type:

Specifies the type of authentication interface for the PAM used by the program, in fact corresponds to the four class interface mentioned earlier:

AUTH: The Authentication class interface module type is used to check the user and password, and to assign permissions;

This type of module provides two services for user authentication. Ask the application to prompt the user for a password or other token to confirm the legality of the user, and to set membership or other priorities through his credentials permission.

Account: Represents the user interface, mainly responsible for checking the legality of the account, to confirm whether the account expires, whether there is permission to login system, etc.;

This module performs an account management based on non-authentication. He is primarily used to restrict/allow users access to a service, the current system resources (up to how many users), and limit the user's location (for example, root can only be logged on through the console).

In most cases, the Auth and account are used together to limit the user's login and use of the service. Such restrictions would be more complete. For example, here is a specific example: login is an application. Login is going to do two things-first querying the user and then providing the user with the services they need, such as providing a shell program. Normally login requires the user to enter a name and password for authentication. When the user name is entered, the system will naturally be compared to whether the user is a legitimate user, whether it exists in a local or remote user database. If the account does exist, then whether it expires. These jobs are the responsibility of the account interface.

If the user satisfies the above sign-in prerequisites, then whether he has the password to log on to the system, whether the password expires, and so on. The job is to be handled by the Auth interface, which usually encrypts the user password information and provides it to local (/etc/shadow) or remote (Ldap,kerberos, etc.) password authentication methods.

If the user is able to log in successfully, the work of Auth and account has been completed. But the entire validation process did not end completely. Because there are some other problems that are not confirmed. For example, how many windows can a user open at the same time on the server, how long the user will be able to use the terminal after logging in, what resources the user can access, what resources they cannot access, and so on. This means that subsequent authentication and environment definitions after login require additional interfaces. Here are the two sets of interfaces we will refer to below:

Session: Conversation class interface. Implementation of the session control from the user login success to exit;

Deal with things that need to be done before/after serving the user. Include: Turn on/off information for exchanging data, monitor directory, etc., set user session environment, etc. This means that this is the final pass before the system formally provides service.

Password: Password class interface. Controls the entire process of user password changes. That is, some of the information said to upgrade the user authentication token.

Note that when using the above interface, each line can only specify one type of interface, if the program requires a variety of interfaces, can be specified in multiple lines.

Second column, Control_flag control bit:

Specifies how to handle the results of the PAM module authentication, in short, to identify what happens after a successful or failed authentication, and how to control it. A single application can invoke a variety of underlying modules, often referred to as "stacking." corresponding to a program in the configuration file in the order in which all modules executed in the "heap", the status of each module in the heap and when the error is processed by the value of the Control_flag bar, his four possible values are required, requisite, sufficient or _optional:

Required: Indicates that the success of the line and the module involved is a necessary condition for the user to authenticate. In other words, the program can pass authentication only if all of the modules that correspond to the application are successful with the required tag. Also, if any module with the required tag has an error, Pam does not immediately return the error message to the application, but instead returns the error message to the program that called him after all the modules have been called. Anyway, it's just that all the modules must be executed once, and any one of the module validation errors, the validation will continue, and the error message will not be returned until the execution is complete. The purpose of this is to not let users know which module they are rejecting and to protect system services in a covert way. Like setting up a firewall rule, the Deny class rule is set to drop, so that when the user is unsuccessful in accessing the network, it is not possible to determine exactly whether it is rejected or the target network is unreachable.

Requisite: Similar to required, only if the module with this tag returns successfully, the user can pass the authentication. The difference is that once it fails, the other modules that follow the heap are no longer executed, and the authentication process ends, and an error message is returned immediately. Compared with the above required, it seems to appear more aboveboard.

Sufficient: Indicates that the line and the validation of the module involved are sufficient conditions for the user to pass the identification. That is, whenever a module marked as sufficient succeeds, Pam returns a successful result to the application without having to try any other module. The same is true even if the subsequent cascading modules use the requisite or required control flags. When a module marked as sufficient fails, the sufficient module is treated as optional. Therefore, the configuration item with the sufficient flag bit does not cause the entire validation failure when the validation error is performed, but the door is open when the validation is successful. Therefore, the use of the control bit must be cautious.

Optional: He says the user can still pass the authentication even if the module validation failed for the line involved. In the PAM system, the module with the token fails to continue processing the next module. This means that even if the specified module fails validation, the user is allowed to enjoy the services provided by the application. Using this flag, the PAM framework ignores the validation errors generated by this module and continues the sequence of execution of the next cascading module.

Include: Represents the invocation of additional Pam profiles during validation. There are quite a number of applications in the RHEL system that implement authentication by fully calling/etc/pam.d/system-auth without having to re-write the configuration item. This also means that in many cases the user can log in to the system and be certified for the vast majority of applications.

There is also a more complex format for the syntax of value = action to set the control flags, which are separated by a space. The format is as follows:

value1 = action1    value2 = Action2    ...

Where value can be the return value of the following Linux Pam libraries:

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, and default.

The last (default) can be used to set the behavior that the above return value cannot express.

Actionn can be either a non-negative integer or one of the following tokens: Ignore, OK, done, bad, die, and reset. If the non-negative integer j, it is necessary to ignore the following J of the same type of module. In this way, the System Manager can more flexibly set up the Cascade module, the stack path of the module is determined by the response of a single module.

A detailed explanation of these marks:

Ignore: If a cascade module is used, the return value of the module will be ignored and will not be known by the application.

Bad: He says the return code should be seen as a sign that the module failed to validate. If this module is the first module to fail validation of the Cascade module, then his state value is the status value and result of the entire stack module validation.

Die: Terminates the cascading module validation process and returns to the application immediately.

OK: Tell Pam that the return value of this module will be used directly as the return value of all cascading modules. That is, if the module in front of the module returns a state of Pam_success, the return value overrides the previous return state. Note: If the return status of the previous module indicates that the module validation failed, then this return value cannot be overridden.

Done: Terminates verification of subsequent cascading modules and immediately returns control to the application.

Reset: Clears the return status of all cascading modules and restarts the validation from the next cascading module.

The third column, Module_path, is the full path name of the module used.

Taking Red Hat Enterprise Linux (RHEL) as an example, it is worth noting that the full path name of the module is different in the i368/i686 and x86_64 systems. So when sometimes the user copies some Pam configuration files from the original system to the new system, if the two system architectures are different, then not modifying the path name of the module may cause Pam to error.

In column four, options are used to pass related options to specific modules, which are then explained by module analysis.

For example, use this bar to open the module debug mode, or to pass a module such as time-out values such as parameters. In addition, he is also used to support the password mapping techniques described below.

If either column has an error or a module is not found, the row is ignored and logged as a critical error.

To this end, the basic architecture of Pam and the basic format of the PAM configuration file have been described in more detail. In the next article, we'll show you how Pam works.

To this end, the basic architecture of Pam and the basic format of the PAM configuration file have been described in more detail. Now we need to see how Pam works.

The working principle and process of Pam:

For the Rhel system, for example, when Pam is installed, there are two major parts: the various Pam modules in the/lib/security directory and the PAM profiles that are already defined for various services and applications under the/ETC/PAM.D and/ETC/PAM.D directories. When an application with a certification requirement needs to be validated, the PAM profile that is responsible for its authentication is typically defined in the application. In vsftpd, for example, there is a line definition in its configuration file/etc/vsftpd/vsftpd.conf:

Indicates that authentication is performed based on the content defined by the/etc/pam.d/vsftpd file when logging in to an FTP server.

So, when the program needs authentication to find the relevant PAM configuration file, how is the authentication process done? Below we will explain by interpreting the/etc/pam.d/system-auth file.

The first thing to declare is: System-auth is a very important PAM configuration file, mainly responsible for user login system certification work. And the file is not only responsible for user login system authentication, other programs and services through the include interface can also call to it, thereby saving a lot of work to re-customize the configuration. So it should be said that the file is the system security master switch and the core PAM configuration file.

Here is the full contents of the/etc/pam.d/system-auth file:

# grep-v ^#/etc/pam.d/system-authauth        required      pam_env.soauth        sufficient    pam_unix.so Nullok Try_ First_passauth        requisite     pam_succeed_if.so uid >= quietauth required        pam_deny.so      account     Required      Pam_unix.soaccount     sufficient    pam_succeed_if.so uid < quietaccount     Required      pam_permit.so password    requisite     pam_cracklib.so try_first_pass Retry=3password    Sufficient    pam_unix.so MD5 shadow Nullok try_first_pass Use_authtokpassword    required      pam_deny.so Session     Optional      pam_keyinit.so revokesession     required      pam_limits.sosession     [Success=1 Default=ignore] pam_succeed_if.so service in Crond quiet use_uidsession     required      pam_unix.so

The first part indicates that when the user logs on, the user identity and password authentication are first identified through the Auth class interface. So in this process, validation passes through several configuration items with Auth.

The first step is to define the environment variables after user login through the pam_env.so module, Pam_env.so allows to set and change environment variables when the user logs on, by default, if no profile is specifically specified, it will be based on/ETC/SECURITY/PAM_ env.conf settings for environment variables after user logon.

Then through the Pam_unix.so module to prompt the user to enter a password, and the user's password and the password information recorded in the/etc/shadow, if the password is correct than the results will allow the user to log in, and the configuration item using the "sufficient" control bit, This means that as long as the validation of the configuration item passes, the user can fully authenticate without having to go to the following authentication. However, in special cases, the user is allowed to log on to the system with a blank password, for example, when a user is removed from the password field in/etc/shadow, the user can simply enter the user name to log in directly to the system.

In the following configuration item, the Pam_succeed_ If.so the user's sign-in conditions are limited to allow users with UID greater than 500 to log in with password Authentication, in the Linux system, the UID of the general system user is within 500, so the item is allowed to use the Useradd command and the default option established by the normal user directly from the local console login system.

Finally, through the pam_deny.so module, all the login requests that do not meet any of the above conditions are rejected directly, PAM_ Deny.so is a special module in which the return value of the module is always no, similar to the configuration guidelines for most security mechanisms, after all authentication rules have been completed, a request for a non-matching rule is rejected directly.

The three configuration items in the second section mainly indicate that the account's legitimacy and login rights are identified through the account class interface.

The first line still uses the Pam_unix.so module to declare that the user needs to pass the password authentication. The second line acknowledges the legality of system users with UID less than 500 in the system. The console is then open for all types of user logon requests.

The third chapter confirms the legality of the password or password used by the user through the password port alternative interface. The first line of configuration items represents the need to call Pam_cracklib to verify the user password complexity. If the user enters a password that does not meet the complexity requirement or the password is wrong, it will return a prompt for the password error after three of such errors, or any correct password validation during the period allows the login. It should be noted that pam_cracklib.so is a commonly used Pam module for controlling the complexity of passwords, and we will describe them in detail later. The two-line configuration items with pam_unix.so and pam_deny.so are then similar to the previous one. Indicates that a password authentication is required and that a login request that does not meet the requirements of any of the above configuration items is rejected directly. However, if the user performs a simple login, this configuration is not functional.

The Forth part will initialize the session connection for the user through session class interface. A few of the more important areas include the use of pam_keyinit.so to create a key ring for a user when they log in and revoke it when the user logs out. However, the control bits configured by the row use optional, indicating that this is not a requirement. The associated pam_limit.so profile is/etc/security/limits.conf, and by default there is no limit for each logged-on user by restricting the session connection resource when the user logs on by pam_limits.so. The configuration method for this module is described in detail later.

It can be seen that different applications use configuration files to invoke different Pam modules during the authentication process to customize the specific authentication process. It is not difficult to see, in fact, according to the actual needs of the PAM configuration files can be modified to meet different certification requirements, such as the following example:

 #%pam-1.0# This file is auto-generated.# User changes'll be destroyed the next time Authconfig is Run.auth requi Red Pam_env.soauth required pam_tally.so onerr=fail Deny=5auth sufficient pam_unix.so Nullok Try_first_passau Th requisite pam_succeed_if.so uid >= Quietauth required Pam_deny.soaccount required Pam_unix.soaccou NT sufficient pam_succeed_if.so UID < quietaccount required Pam_permit.sopassword requisite pam_cracklib.so Try_first_pass retry=3 minlen=10 lcredit=-1 ucredit=-1 dcredit=-1 ocredit=-1 difok=6password requisite pam_passwdqc.so Use_first_pass Enforce=everyonepassword sufficient pam_unix.so MD5 remember=6 shadow Nullok Try_first_pass USE_AUTHTOKP Assword Required Pam_deny.sosession Optional pam_keyinit.so revokesession required pam_limits.sosession [su Ccess=1 Default=ignore] pam_succeed_if.so service in Crond quiet use_uidsession required pam_unix.so 

In this case, the restrictions on the complexity of user password modification, the locking limit after the user repeatedly entered the password, and the user's password history and other restrictions are added.

Therefore, we have increased the security requirements of user login verification to a large extent by modifying the above System-auth configuration file, increasing the module and changing the options. We'll explain the configuration in detail later in the article.

It is also important to note that the logical order of configuration items and module invocations is critical throughout the PAM configuration file. Because Pam is validated according to the order of the configuration items. The wrong sequence of module calls is likely to cause serious security problems or even system errors. It is important to consider this when modifying the PAM configuration.

Linux Pluggable authentication Module (PAM) configuration file, working principle and process