This article describes the concept of Linux-PAM and analyzes the architecture of Linux-PAM with readers. The author hopes to help readers better understand Linux-PAM, in order to have a deeper grasp of it. 1. what is Linux-PAM? for security reasons, the computer system only goes through... this article describes the concept of Linux-PAM and analyzes the architecture of Linux-PAM with readers. The author hopes to help readers better understand Linux-PAM, in order to have a deeper grasp of it. 1. what is Linux-PAM? for security reasons, the computer system can only be accessed by authorized legal users. how to correctly identify the real identity of users is a key issue. User identification is a process in which a user submits his/her identity creden。 to the system in a secure manner, and then the system determines whether the user's identity is true. In other words, user authentication is the portal of the system. each user must be authenticated when entering the system. Initially, the user authentication process for Linux systems is like that for various Unix systems: the system administrator creates an account for the user and specifies a password for the user, the user uses the specified password to log on and then reset his password, so that the user has a secret password only known to him. Generally, users' passwords are encrypted and stored in the/etc/passwd file. When a user logs on, the logon service program prompts the user to enter the user name and password, and then encrypts the password and compares it with the encrypted password of the corresponding account in the/etc/passwd file. if the password matches, indicates that the user's identity is true and allows the user to access the system. This idea is based on the user's own password. if the entered password is correct, the system determines that the user is the one he claims. Later, many other methods were used to identify users, such as Kerberos for the network environment and smart card-based authentication systems. However, these authentication schemes have a common problem: the code that implements the authentication function is usually compiled together as part of the application, this is the problem ------ if you find that the algorithm used has some defects or want to use another identification method, you have to rewrite (modify or replace) and re-compile the original program. Obviously, our original identification scheme lacks flexibility, and it is annoying to take a long breath. For the above reasons, people began to look for a better alternative: On the one hand, the identification function is independent from the application, modular design, implementation and maintenance; on the other hand, establish standard APIs for these authentication modules so that each application can conveniently use the various functions they provide. Meanwhile, the authentication mechanism applies to upper-level users (including applications and end users) is transparent. Until 1995, SUN's researchers proposed a solution to meet the above requirements-plug-in Authentication Module (PAM) mechanism, which was partially implemented on its operating system Solaris 2.3 for the first time. Plug-In Authentication Module (PAM) adopts modular design and plug-in functions, so that we can easily insert a new authentication module in the application or replace the original components, without having to make any changes to the application, the software can be customized, maintained, and upgraded more easily-because the authentication mechanism is relatively independent from the application. Applications can easily use the various authentication functions provided by PAM through the pam api, without having to know much about the underlying details. In addition, PAM is also easy to use, mainly because it shields the specific details of the identification on the upper layer, so users do not have to be forced to learn a variety of identification methods, nor do they have to remember multiple passwords; because it implements the integration of multiple authentication mechanisms, a single program can easily integrate multiple authentication mechanisms, such as the Kerberos authentication mechanism and Diffie-Hellman authentication mechanism, however, the user can still log on with the same password, but does not feel that different authentication methods have been adopted. With the efforts of developers, various versions of UNIX systems gradually provide support for PAM. Specifically, Linux-PAM is implemented 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 all provide support for PAM. FreeBSD supports PAM from version 3.1. Note that apart from the specific implementation, the PAM frameworks on various versions of Unix systems are the same, so the Linux-PAM framework knowledge we will introduce here is universal. Therefore, we can see from the introduction of the framework below that we have not deliberately distinguished the terms PAM and Linux-PAM. II. PAM hierarchical architecture PAM adopts a hierarchical design concept to implement plug-in functions and ease of use: to ensure that each authentication module is independent from the application, the pam api is used as the link between the two, so that the application can flexibly insert the authentication function module as needed, thus realizing the "authentication function, ". In fact, this idea is very consistent with the "high cohesion and low coupling" idea in software design. the PAM system is shown in the following figure:
The PAM architecture shows that the pam api plays an important role in connecting applications and authentication modules. When an application calls the pam api, the application interface layer follows the configuration file pam. conf, load the corresponding authentication module. Then pass the request (the parameter obtained from the application) to the underlying authentication module. then, the authentication module can perform specific authentication operations as required. After the authentication module completes the corresponding operation, it returns the result to the application interface layer, and then the interface layer returns the response from the authentication module to the application according to the specific configuration. It describes the components of PAM and their overall operating mechanism. Next we will introduce the key low layer 2 of PAM. 3. Layer 1: The module layer is at the bottom of the entire structure and provides user identification and other services to the interface layer, that is to say, all the specific identification work is done by the modules at this layer. Some applications not only need to verify the user's password, but may also need to verify that the user's account has expired. In addition, some applications may require recording information about the current session or changing the password. Therefore, in addition to providing the authentication module at the module layer, PAM, it also provides modules that support account management, session management, and password management. Of course, these four modules are not necessary for all applications, but flexible trade-offs as needed. for example, although login may require access to all four modules, however, su may only need to use the identification component. The interface-layer pam api and configuration file are involved in the trade-off. This part will be described below. 4. Layer 2: application interface layer the application interface layer is located in the middle of the PAM structure. it shields the application from the details of user authentication and other processes, call down the specific services provided by the specific modules in the module layer. It consists of pam api and configuration file. PAM APIs can be divided into two types: one is used to call the interfaces of lower-layer specific modules. these interfaces correspond to the underlying modules: 1. authentication Interface: pam_authenticate () is used to identify users, and pam_setcred () is used to modify users' secret information. 2. account interface: pam_acct_mgmt () checks whether the account held by the authenticated user has the right to log on to the system and whether the account has expired. 3. session interface: includes pam_open_session () and pam_close_session () functions for session management and accounting. 4. password interface: includes pam_chauthtok () used to modify the user's password (). The second type of interfaces usually do not correspond to the underlying modules. they provide support for the underlying modules and implement communication between applications and modules. Details: 1. management interface each group of PAM transactions starts from pam_start () and ends with the pam_end () function. Interfaces pam_get_item () and pam_set_item () are used to read and write status information related to PAM transactions. In addition, pam_str () can be used to output the PAM interface error information. 2. during application initialization, some data such as user names can be stored in the PAM interface layer through pam_start () for future use by underlying modules. In addition, the underlying module can use pam_putenv () to pass specific environment variables to the application, and then the application uses pam_getenv () and pam_getenvlist () to read these variables. 3. the pam_start () function of the communication interface between the user and the module allows the underlying module to read and write the module-related identification information through a session callback function, for example, the user is prompted to enter the password as specified by the application. 4. inter-Module communication interfaces although each module is independent, they can still share some public information related to the authentication session through the pam_get_item () and pam_set_item () interfaces, such as the user name, service name, and password. In addition, these APIs can be used to allow applications to modify status information after pam_start () is called. 5. interfaces pam_get_data () and pam_set_data () for reading and writing module status information are used to access and update information of specific modules according to PAM handle requirements. In addition, you can add a data clearing function after these modules to clear the scene when pam_end () is called. Because the PAM module is loaded as needed, the initial task of each module is completed during the first call. If the cleanup tasks of some modules must be completed at the end of the authentication session, they should use the pam_set_data ()-defined cleanup functions that will call pam_end () in the application () the API is called. 5. the configuration file is also placed in the application interface layer. it is used with pam api to flexibly insert the required authentication module in the application. It mainly serves to select a specific identification module for the application, a combination of modules, and define the behavior of modules. The following is an example configuration file :. as shown in the sample configuration file, the configuration file consists of many registration items (each row corresponds to one registration item), and each row is divided into five columns (each column corresponds to one column). the detailed explanation is as follows: in the first column, service indicates the application that uses PAM, such as login, passwd, and rlogin. OTHER in this column indicates all applications not explicitly listed in this file. That is to say, if all programs have the same requirements, the entire configuration file only needs one line, and the first column of this line is OTHER. In this example, because all applications use the same session module, you can use a single row, that is, "OTHER auth required pam_unix_auth.so", to replace these rows in the file: "login session required pam_unix_session.so ftp session required pam_unix_session.so telnet session required pam_unix_session.so ". In the second column, module_type indicates the type of the PAM underlying module used by the program. auth indicates the authentication module, account indicates the account module, session indicates the session module, and password indicates the password module. Note: each line can only specify one type of module. if the program requires multiple modules, you can specify them in multiple lines. In 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 usually called "stacks". This corresponds to all modules executed by a program in the order displayed in the configuration file ", the position of each module in the heap and the handling of errors are determined by the value in the control_flag column. The five possible values are required, Requisite, sufficient, and _ optional. The following is an introduction: required -- it indicates that the success of this module is necessary for the user to pass the authentication. In other words, only when all modules with the required mark corresponding to the application are successful, this program can pass authentication. At the same time, if any module with the required mark has an error, PAM does not immediately return the error message to the application, the program that calls the error message is returned only after all modules are called. Requisite-similar to required. Users can identify a module with this mark only after it returns a successful result. The difference is that it does not execute other modules behind the heap once it fails, the identification process ends here. Optional -- it indicates that the user can pass the authentication even if the module fails. In the PAM system, the module with this mark will continue to process the next module after it fails. Sufficient -- it indicates that the successful completion of the module is a sufficient condition for the user to pass the authentication, that is, once the module marked as sufficient succeeds, PAM immediately returns success to the application without having to try any other modules. When the module marked as sufficient fails, the sufficient module is treated as optional. In the fourth column, module_path indicates the position of the PAM module. In the fifth column, options is used to pass related options to a specific module. then, the module analyzes and interprets these options. For example, you can use this column to open module debugging, or pass parameters such as timeout values to a module. It is also used to support the password ing technology described below. If an error occurs in any column or a module is not found, the row is ignored and recorded as a serious error. In this example, the login program uses the UNIX password module for authentication, while the ftp program uses the S/Key module for authentication. If we want to change the ftp program's authentication method, for example, using the UNIX password module for authentication, then we do not have to change the source program, you only need to change the ftp auth required pam_skey_auth.so debug in the configuration file to ftp auth required pam_unix_auth.so debug. when you use ftp, you will use the traditional UNIX password authentication method to verify your identity. It can be seen that it is easy to change the authentication mechanism for applications under the PAM system. In addition, the stack function of the PAM system also enables applications to support multiple identification mechanisms. in the following example, the login program has three registration items related to identification in the configuration file :. the sample configuration file first uses the pam_unix.so module, that is, the traditional UNIX password method, to authenticate the user when the login program is executed, and then calls the pam_kerb.so module, that is, Kerberos, to authenticate the user, finally, the pam_rsa.so module is used to identify users in RSA mode. In the process of user identification in the above order, if the pam_unix.so module fails to authenticate, it will continue to call the following module for authentication rather than immediately returning an error message to the login program; the pam_kerb.so module is also processed in the same way. after the last pam_rsa.so module is processed in sequence, PAM returns the preceding error information to the login program. For this configuration, even if the pam_rsa.so module passes smoothly, as long as there is an error in the pam_unix.so module and the pam_kerb.so module, the user cannot pass the authentication. On the contrary, even if the pam_rsa.so module fails, as long as the pam_unix.so module and pam_kerb.so module both pass, the user can also pass the authentication. 6. multiple authentication mechanisms are used for password ING on the same machine. in particular, the integration of multiple authentication mechanisms by one application may cause users to remember multiple passwords, which may make users feel uncomfortable. Although the same password can be used by all mechanisms for ease of use, it will weaken the security of the system-if the password of any mechanism is leaked, all mechanisms will be affected. In addition, different authentication mechanisms may have their unique requirements in terms of password length, allowed characters, update interval, and validity period, these requirements must also be considered when using the same password for multiple authentication mechanisms. PAM provides us with a solution that does not rule out sharing a password for all authentication mechanisms, and allows different passwords for each mechanism through password ING. This scheme uses the user's "primary password" to encrypt other "secondary passwords" and stores these encrypted secondary passwords in a place that the user can access. Once the master password has been 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 ing ". If the password ING is incorrect or the ING does not exist, the authentication modules should prompt the user to enter the password. To support password ING, the master password must be provided to the authentication modules of the stack when the PAM layer 2 is required. At the same time, the password should be cleared before the pam_authenticate function returns. To ensure the security of password ING, the master password must be strong enough. you can consider other effective measures, such as making it longer, making it of diverse types of password characters, and using mixed types of characters to form a password. Encryption and storage of passwords depend entirely on the specific implementation: it can store encrypted sub-passwords (also known as "ing passwords") in reliable or unreliable places, such as smart cards, local files, or directory services. Of course, if the encrypted password is stored in an unreliable place that allows public access, it will leave dictionary attacks. To implement password ING, all authentication modules should support the following four ing options: 1. use_first_pass: indicates that when the module is executed, the user is not prompted to enter the password, but the master password prompted to the user before the module is used as their public password for verification. If the user fails to pass the primary password authentication, the module does not prompt the user to enter the password. This option is generally used when the system administrator wants to force the same password to pass through multiple modules. 2. try_first_pass: except if the primary password is incorrect, the user will be prompted to enter the password. its usage is the same as use_first_pass. 3. use_mapped_pass: it indicates that a valid password for this module is obtained using password ing technology. That is to say, when the module is executed, the user is not prompted to enter the password. Instead, the ing password is used to authenticate the sub-password of the module obtained by the master password for verification. If the user fails to pass the primary password authentication before that, the module will not prompt the user to enter the password. 4. try_mapped_pass: except if the master password is incorrect, the system prompts the user to enter the password. this parameter is used in the same way as use_mapped_pass. After the password is changed, PAM saves all the new and old passwords and enables the relevant modules to access them. Other modules can use this information to update the encrypted password without forcing the user to enter the password again. The following configuration file is used as an example to describe password ing :. the sample configuration file here the login program integrates three authentication methods: traditional UNIX password authentication, Kerberos authentication, and RSA authentication, but usually the user can pass the authentication only once. When the program calls the pam_unix.so module, PAM prompts the user to enter their UNIX password, and then the pam_kerb.so module authenticates the UNIX password entered by the user. Call the pam_kerb.so module. because the module has the use_mapped_pass option, it uses the password ing mechanism for authentication. that is to say, if the UNIX password authentication is successful, use it as the master password of the pam_kerb.so module to decrypt its ing password for Kerberos authentication. If the password required by the pam_unix.so module fails to pass verification, the password ing cannot be performed, PAM will directly call the next authentication module without prompting the user to enter its Kerberos password. The option of the last module is use_first_pass. Therefore, the pam_rsa.so module uses the master password entered in the front to authenticate the user. if the password is incorrect, the system does not prompt the user to enter the RSA password. Therefore, as long as the password entered for the first time is correct and the ing password exists, a password is sufficient to pass authentication. VII. Conclusion Linux-PAM is a flexible and powerful user identification mechanism. This article analyzes its composition structure and the relationship between each part, hope to help readers understand the PAM mechanism. Han Bo, a freelance writer, has nearly 10 years of experience in C programming. he is mainly interested in TCP/IP protocol, Linux kernel, and information security technology. As a freelance writer, he strives to put the content he wants to express in plain and easy-to-understand form without affecting the essence of the problem. You can contact him via hbzzx2001@yahoo.com.cn.
