Determine Linux PAM Architecture
content:
What is Linux-Pam?
PAM hierarchical architecture
First layer: module layer
Layer 2: Application Interface Layer
Profile
Password mapping
Conclude
About author
information feedback
In the Linux area:
Tutorial
Tools & products
Code and components
project
article
Hanbo (hbzzx2001@yahoo.com.cn) July 2003
This article describes the concept of Linux-Pam, and also analyzes Linux-Pam architecture with the reader, and the author hys hope that the reader's understanding of the Linux-Pam in order to have a deeper level.
First, what is Linux-PAM for security, the computer system has only authorized legitimate users to access, and how to properly identify the true identity of the user here is a key issue. The so-called user authentication is that the user submits its own identity to the system, and then confirms whether the user's identity is true. In other words, the user is identified by the system's portal, and each user enters the system must be authenticated. Initially, the user authentication process of the Linux system is like a variety of UNIX systems: the system administrator creates an account for the user and specifies a password for it, and the user uses this specified password to reset its password, so that the user has A secret password that only he knows. In general, the user's password is stored in the / etc / passwd file after encryption. When the user logs in, the login service program prompts the user to enter its username and password, and then compare the password and compare the encryption password of the / etc / passwd file. If the password matches, explain the user's identity and allows this user to access this user system. This kind of thought is based on only the user knows his password, so the password entered is correct, then the system determines that he is the person claimed. Later, many other methods of identifying users are also used, such as Kerberos for network environments, and smart card-based authentication systems. However, these authentication options have a common problem: code that realizes the authentication function is usually compiled as part of the application, so that the problem is coming ------ If the algorithm used is found to have some defects or want to adopt another identification method When the user has to rewrite (modify or replace) and then recompilate the original program. Obviously, our original identification plan lacks flexibility, the situation here is very annoyed. In view of the above reasons, people have begun to find a better alternative: on the one hand, the identification function is independent from the application, and modular design, implementation, and maintenance separately; on the other hand, establish a standard API for these authentication modules for Each application can easily use the various functions provided; at the same time, the authentication mechanism is transparent to its upper user (including applications and end users). Until 1995, Sun's researchers proposed a solution that satisfies the above needs - Plug-in Identification Module (PAM) mechanism and first implemented in its operating system Solaris 2.3. The plug-in authentication module (PAM) mechanism adopts modular design and plug-in capabilities such that we can easily insert new authentication modules or replace the original components in the application without having to make any modifications to the application, thereby making software customization , Maintenance and upgrade is more relaxed - because the authentication mechanism is relatively independent between applications. The application can easily use the various authentication functions provided by the PAM API without having to know too much underlying detail. In addition, the ease of use of PAM is also strong, mainly in its specific details of the identification of the upper layer, so users don't have to be forced to learn a variety of differential ways, and don't have to remember multiple passwords; The integrated problem of multi-identification mechanism, so a single program can easily integrate a variety of authentication mechanisms such as Kerberos authentication mechanisms and Diffie - Hellman authentication mechanisms, but users can still use the same password to be logged in and do not adopt a variety of different identification methods. . Under the efforts of the major developers, each version of UNIX system has provided support for PAM. Among them, Linux-PAM is implemented specifically for Linux machines, including Caldera 1.3, 2.2, Debian 2.2, Turbo Linux 3.6, Red Hat 5.0, and SUSE 6.2 and their subsequent versions are supported for PAM. FreeBSD supports PAM from version 3.1.
It should be noted that in addition to specific implementation, the framework of PAM on various versions of the Unix system is the same, so we are universal in the Linux-PAM framework knowledge introduced here. Therefore, it can be seen in the process of introducing its framework, we don't deliberately distinguish between PAM and Linux-Pams. Second, PAM hierarchical architecture PAM In order to achieve its plug-in function and ease of use, it takes a hierarchical design idea: let each authentication module is independent from the application, then pass the PAM API as a link to the link, so The application can flexibly "insert" as needed to authenticate the function module to truly implement the "authentication function, and response". In fact, this idea is very compliant with "high polymerization, low coupling" in software design. The PAM system is shown in the following: Figure 1 The PAM architecture can be seen from the above figure, the PAM API plays Under the work, it is a link between the application and the authentication module: When the application calls the PAM API, the application interface layer loads the corresponding authentication module according to the provisions of the configuration file PAM.CONF. Then passes the request (ie, the parameters obtained from the application) to the underlying authentication module, and the authentication module can perform the specific authentication operation as required. When the authentication module performs the corresponding operation, return the result to the application interface layer, and then returns a response from the authentication module to the application based on the configuration of the configuration. The respective components of the PAM are described above, and they are used as the overall operation mechanism. The key low second layer of PAM will be described below. Third, the first layer: The module layer module layer is at the bottom of the entire structure, which provides user authentication such as the interface layer, which means that all specific authentication work is done by the module of the layer. For applications, some not only need to verify the password of the user, but also may request that the user's account has expired. In addition, some applications may also request information or change passwords for recording the current session, so PAM provides a module that supports account management, session management, and password management functions in the module layer. Of course, these four modules are not necessary, but the flexibility to pay, for example, although login may request access to all four modules, the SU may only need to use the authentication component. As for how to pay, it involves the PAM API and configuration file of the interface layer, which will be described below. Fourth, the second layer: Application interface layer Application interface layer is located in the middle part of the PAM structure, which is to block the specific details of the process of user authentication, to call the specific service provided by the specific modules in the module layer. As can be seen from Figure 1, it is mainly composed of two parts: PAM API and configuration files, and will be described below. The PAM API can be divided into two categories, one is used to call the interface of the lower layer specific module, such an interface corresponds to the underlying module:
Identification class interface: PAM_AUTHENTICATE () is used to identify users, and PAM_SETCRED () is used to modify the secret information of the user. Account Class Interface: PAM_ACCT_MGMT () Checks if the account held by the authenticated user has the right to log in, and whether the account has expired. Session interface: includes a PAM_OPEN_SESSION () function for session management and billing. Password interface: including PAM_CHAUTHTOK () for modifying user passwords. The second type of interface is usually not corresponding to the underlying module, and their role is to provide support for the underlying module and implement communication between the application and the module. details as follows:
The administrative interface starts from PAM_START () each set of PAM_Start () ends the PAM_END () function. Interface PAM_GET_ITEM () and PAM_SET_ITEM () are used to read and write status information related to PAM transactions. At the same time, the error information of the PAM interface can be output with the PAM_STR (). The communication interface between the application and the module is during application initialization, and some data such as the username can be stored in the PAM interface layer through PAM_START () for future use of the underlying module. In addition, the underlying module can also pass a specific environment variable to the application using PAM_PUTENV (), and then read these variables using PAM_GETENV () and PAM_GETENVLIST (). The communication interface PAM_START () function between the user and the module can make the underlying module pass the authentication information related to the write module, such as the application specified in the application, for example, prompting the user input password. Module Inter-module Although each module is independent, they can still share certain public information related to the authentication session through the PAM_GET_ITEM () interface, such as user name, service name, password, etc. In addition, these APIs can also be used to make the application modify status information after calling PAM_START (). The interface interface of the read and write module status information is used to access and update the information of the particular module in accordance with the PAM handle asking. In addition, an additional data function can be attached to these modules to clear the site when the PAM_END () is called. Since the PAM module is loaded with the PAM module, each module is initiated when the task is completed in the first call. If the clearance task of some modules must be completed at the end of the authentication session, they should use the PAM_SET_DATA () to clear the function, which will be called when the function of the clerution task will be called when the application calls the PAM_END () interface. 5. Profiles We noticed that the configuration file is also placed in the application interface layer, which is used with the PAM API to achieve the purpose of flexible inserting the required authentication module in the application. Its role is mainly for the application of the specific authentication module, the combination between the modules, and the behavior of the specified module. Below is an example configuration file: Figure 2. Sample profile We can see that there are many registries (corresponding to a registration item per line), each line is divided into five columns (each column corresponding column), detail Explain the following: The first column, service represents the use of PAM, such as login, passwd, rlogin, etc. Other in this column indicates that all applications not explicitly listed in this file. That is, if all programs have the same requirements, the entire configuration file only needs one line, and the first column of the row is Other. In this example, since all applications use the same session module, you can actually use a single line, ie "Other Auth Required Pam_Unix_Auth.so"
Instead of these lines in the file:
"Login Session Required Pam_Unix_Session.so
FTP Session Required Pam_Unix_Session.so
Telnet Session Required Pam_Unix_Session.so ".
The second column, Module_Type specifies the type of PAM underlying module used by the program: Auth represents the authentication class module; Account Represents the account class module; session represents the session module; Password means the password module. Note that each line can only specify a type of module. If the program requires multiple modules, it can be specified in multiple rows. The third column, control_flag specifies how to handle the success and failure of the module. A single application can call multiple underlying modules, which are often referred to as "stack", corresponding to all modules performed in the order in the configuration file into "stack", the status of the modules in the heap and the error time Decided by the value of the Control_Flag column, it is required for Required, Requisite, Sufficient or _Option, which is now described below: Required - It indicates the necessary conditions of the module, in other words In other words, the program can only be authenticated after all the modules with the Required tag with the application of the application. At the same time, if there is an error with the module with the Required tag, PAM does not immediately return the error message to the application, but after all modules are called, return the error message to call it. Requisite - It is similar to the required, only the module with this mark returns successfully, the user can pass the authentication, and the difference is that the other modules behind the heap are no longer executed, and the authentication process ends here. Optional - It represents even if the module fails, the user can still authenticate. In the PAM system, the next module will continue after the module with the marker fails. Sufficient - It indicates that the module succeeds is that the user's adequate condition is identified, that is, as long as the module marked as suficient is successful, then PAM immediately returns success without having to try any other modules. When the module marked as suficient fails, the sufficient module is treated as an Optional. The fourth column, Module_path points to the location of the PAM module. The fifth column, Options is used to pass related options to a particular module and then interpreted these options by module analysis. For example, use this column to open module debug, or pass parameters such as timeout values to a module. In addition, it is also used to support password mapping techniques described below. If there is an error in any column, or a module is not found, the line is ignored and recorded as a serious error. In this case, the login program uses the UNIX password module to authenticate, but the FTP program uses the S / KEY module to authenticate. If we want to change the authentication method of the FTP program, if we use the UNIX password module to identify, then we don't have to change the source program, just need to convert FTP auth request pam_skey_auth.so debug in the configuration file
Change to
FTP Auth Required Pam_unix_AUTH.SO Debug
Thus, when the user uses FTP, it will authenticate its identity with a conventional UNIX password. It can be seen that it is a relaxed thing to change the identification mechanism for the application under the PAM system. In addition, the stacking function of the PAM system also enables the application to support a variety of authentication mechanisms, such as the login program in the following examples, three registrations related to the identification: Figure 3. Sample profile When the login program is executed I used the PAM_UNIX.SO module to authenticate the user, then call the PAM_kerb.so module, Kerberos authenticate, and finally identify the user in the RSA mode using the PAM_RSA.SO module. Decimation of the user in the above order, if the PAM_UNIX.SO module fails, it will continue to call the following module to authenticate rather than return an error message to the Login program; PAM_kerb.so module is also handled in the same manner until sequential processing After the last PAM_RSA.SO module, PAM returns the error message appearing to the Login program. For this configuration, even if the PAM_RSA.so module passes smoothly, as long as the PAM_UNIX.SO module and the PAM_KERB.SO module have an error, the user cannot pass the authentication; the other, even if the PAM_RSA.SO module fails, as long as the PAM_UNIX.SO module and PAM_kerb The .so module passes, the user can also pass the authentication. 6. Password mapping uses multiple authentication mechanisms on the same machine, especially an application integration, multiple authentication mechanisms, may cause users to remember multiple passwords, which will make users feel uncomfortable. Although all mechanisms can be used to obtain ease of use, this will weaken the security of the system - if any of the mechanisms are leaked, all mechanisms will be trailed. In addition, different authentication mechanisms may have their unique requirements in password length, allowable characters, update intervals, and validity, etc., which are also a problem that must be considered for the use of the same password for multiple identification mechanisms. PAM provides us with a solution that does not exclude a password for all authentication mechanisms while allowing each mechanism to use different passwords through password mapping techniques. The program uses the user's "primary password" to encrypts other "sub-password" and stores these encrypted sub-passwords in a place that users can access. Once the main port is verified, the authentication module can use it to decrypt those encrypted sub-passwords to obtain the corresponding password, and then pass the required password to the authentication module. This is called "password mapping". If the password mapping occurs, or if the mapping does not exist, each authentication module should prompt the user to enter the password. To support password mapping, the main channel should be saved at the second layer of the PAM and each authentication module supplied to the stack is required. At the same time, the password is to be cleared before the PAM_AUTHENTICATE function returns. In order to protect the security of the password mapping, the main port must be strong enough to consider effective measures such as a longer length, form a password character, and use a hybrid type character composition password. How to encrypt the password and its storage is completely dependent on the specific implementation: it can store the encrypted sub-password (also known as "mapping port") in a reliable or unreliable place, such as a smart card, a local file or directory service. Of course, if the encrypted password is saved in a place where unreliable allows public access, there will be hidden dangers that are attacked by dictionary. To implement the password map, all authentication modules should support the following four mapping options:
USE_FIRST_PASS: It indicates that the module does not prompt the user input password when the module is executed, and the main password previously prompted before the module is verified as their public password. If the user cannot authenticate through the main password, the module does not prompt the user to enter the password. This option generally uses when the system administrator wants to force the same password to pass multiple modules. Try_first_pass: In addition to if the main port is incorrect, it will prompt the user input password, which is the same as using using_first_pass. Use_mapped_pass: It represents a valid password for this module using the password mapping technology. That is, the module does not prompt the user input password, but is verified by the mapping password, that is, the module decrypted by the main port is verified as the password input of the module. If the user cannot pass the primary password before this, the module does not prompt the input password. TRY_MAPPED_PASS: In addition to if the main channel is incorrect, it will prompt the user input password, which is the same as the USE_MAPPED_pass usage. When the password is replaced, the PAM saves all new adventures and enables the module to access them. Other modules can use this information to update the encrypted password without enforcing the user again. Now the following profile is explained as an example to explain the interpretation map: Figure 4. Sample configuration file integrates three authentication methods here: traditional UNIX password authentication, Kerberos and RSA identification, but usually, users can only enter only one password By identifying. When the program is called the PAM_UNIX.SO module, the PAM prompts the user to enter their UNIX password, and then authenticate the Unix password entered by the PAM_kerb.so module. This will then call the PAM_kerb.so module, because the module is option for use_mapped_pass, it will use the password mapping mechanism to authenticate, that is, if the Unix password is passed, it is decrypted as the main password of the PAM_kerb.so module to decrypt its correspondence. Map password thus performs Kerberos identification. If the password required by the PAM_UNIX.SO module cannot be verified, the password mapping cannot be performed, then the PAM will directly call the next authentication module without prompting the user to enter its Kerberos password. The last module option is used_first_pass, so the PAM_RSA.SO module will authenticate the user using the main port input, if the password error does not prompt the user to enter the RSA password. So, as long as the password entered for the first time is correct, the mapping password exists, one password is sufficient to pass identification. 7. Conclusion Linux-PAM is a user authentication mechanism that uses flexible functions. This article analyzes the relationship between its composition and parties, and hopes to help readers understand the mechanism of PAM. About the author Han Bo, freelance writer, has nearly ten years of C language programming experience, mainly interested in the field of TCP / IP protocol, Linux kernel, and information security technology. As a freelance writer, it is strive to be in front of the reader in the form of the reader in the form of a common form without affecting the substance of the problem. You can contact him through hbzzx2001@yahoo.com.cn.
