<Transferred from in-depth Linux Pam architecture>
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 the sake of security, computer systems 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, so the problem arises ------ if you find
When the algorithm used has some defects or you want to adopt another authentication 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 suse6.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. Hierarchical Architecture of Pam
Pam adopts a hierarchical design concept to implement its plug-in functions and ease of use: it allows the identification modules to be independent from the application, and then uses pamapi as the link between the two, in this way, the application can flexibly Insert the identification function module as needed, so as to truly implement the "identification function, as needed ". 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:
Figure 1 Pam Architecture
It can be seen that the pam api is a link between the application and the authentication module. When the 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.
The Module layer is at the bottom of the entire structure. It provides user identification and other services to the interface layer. That is to say, all specific authentication work is done by the modules of 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, soPamIn addition to the authentication module, the module layer 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 LayerPamAPI and configuration file, which will be described below.
The application interface layer is locatedPamThe middle part of the structure, which shields the application from the specific details of user authentication and other processes, and calls down the specific services provided by the specific modules in the module layer. As shown in figure 1, it mainly consistsPamAPI and configuration file.
PamAPIS can be divided into two types: one is used to call interfaces of lower-layer specific modules. These interfaces correspond to the lower-layer modules:
- Identification interface:Pam_ Authenticate () is used to identify users,Pam_ Setcred () is used to modify users' secret information.
- Account interface:Pam_ Acct_mgmt () check whether the account held by the authenticated user has the right to log on to the system, and whether the account has expired.
- Session interface: includesPam_ Open_session () andPam_ Close_session () function.
- Password interface: includesPam_ Chauthtok ().
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. The details are as follows:
- Management Interface
Each groupPamTransaction slavePam_ Start () starts and endsPam_ End () function. InterfacePam_ Get_item () andPam_ Set_item () is used to read and writePamTransaction-related status information. At the same timePam_ STR () OutputPamInterface error information.
- Communication interfaces between applications and modules
During application initialization, some data such as user names can be passed throughPam_ Start () stores it inPamInterface Layer for future use by underlying modules. In addition, the underlying module can also be usedPam_ Putenv () transmits specific environment variables to the application, and then the application usesPam_ Getenv () andPam_ Getenvlist () reads these variables.
- Communication interfaces between users and modules
PamThe _ start () function allows the underlying module to read and write the authentication information related to the module through a session callback function, for example, prompting the user to enter a password as specified by the application.
- Inter-module Communication Interface
Although the modules are independent, they can stillPam_ Get_item () andPamThe _ set_item () interface shares some common information related to the authentication session, such as the user name, service name, and password. In addition, these Apis can be used to callPamAfter _ start (), let the application modify the status information.
- Interface for reading and writing module status information
InterfacePam_ Get_data () andPam_ Set_data () is used accordingPamThe handle must access and update the information of a specific module. In addition, you can add a data clearing function after these modules so that when you callPam_ End () to clear the site.
BecausePamThe module is loaded as needed, so the initial tasks of each module are completed during the first call. If the cleanup tasks of some modules must be completed at the end of the authentication session, they should usePam_ Set_data () specifies the clearing function. The functions that execute the clearing task will be called in the application.PamThe _ end () interface is called.
We noticed that the configuration file is also placed in the application interface layer.PamBy using APIs, You can flexibly Insert the required authentication module into your 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:
Figure 2. sample configuration file
We can see that the configuration file consists of many registration items (each row corresponds to one registration item), each row is divided into five columns (each column corresponds to one column), the detailed explanation is as follows:
In the first column, the Service indicates thatPamApplications, 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 line, that is
" OTHER auth required pam_unix_auth.so"
To replace the rows in the file:
"login session required pam_unix_session.softp session required pam_unix_session.sotelnet session required pam_unix_session.so"。
In the second column, module_type indicates the program usedPamType of the underlying module: 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,PamInstead of returning the error message to the application immediately, 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. InPamIn the system, the module with this tag 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 to say, once the module marked as sufficient succeedsPamImmediately 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 indicatesPamModule location.
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, we only need
ftp auth required pam_skey_auth.so debug
Change
ftp auth required pam_unix_auth.so debug
In this way, when you use ftp, you will use the traditional UNIX password authentication method to verify your identity. It can be seen that inPamIn the system, it is easy to change the identification mechanism for applications. In addition,PamThe stack function of the 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:
Figure 3. sample configuration file
UsePamThe _ Unix. So module identifies users using the traditional Unix Password method and then callsPamThe _ curb. So module, that is, Kerberos, authenticates users and usesPamThe _ RSA. So module identifies users through RSA. In the process of identifying users in the above order, ifPam_ The 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;PamThe _ curb. So module is also processed in the same way until the last one is processed in sequence.PamAfter the _ RSA. So module,PamThe preceding error message is returned to the login program. For this configurationPamThe _ RSA. So module passes smoothly as longPam_ Unix. So module andPamIf an error occurs in the _ curb. So module, the user cannot pass the authentication. On the contraryPam_ RSA. So module failed, as longPam_ Unix. So module andPamThe _ curb. So module has passed, and the user can also pass the authentication.
Multiple authentication mechanisms are used 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.
PamIt 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 primary password must existPamThe second layer is provided to each Identification Module of the stack when necessary. At the same time, the password must bePamThe _ authenticate function is cleared before return. 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:
- 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.
- Try_first_pass: except if the primary password is incorrect, you are prompted to enter the password. The usage of try_first_pass is the same as that of use_first_pass.
- 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.
- Try_mapped_pass: except if the primary password is incorrect, it prompts the user to enter the password. This item is used in the same way as use_mapped_pass.
After the password is changed,PamAll old and new passwords are saved, and relevant modules can 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:
Figure 4. sample configuration file
Here, the login program integrates three authentication methods: Traditional Unix Password Authentication, Kerberos authentication, and RSA Authentication. However, generally, the user can pass the authentication only once. When the program callsPam_ Unix. So module,PamPrompt the user to enter their UNIX password, and thenPamThe _ curb. So module identifies the UNIX password entered by the user. Then callPam_ Curb. So module, because the option of this module is use_mapped_pass, it will use the password ing mechanism for authentication, that is, if the Unix Password Authentication is passed, it will be usedPamThe master password of the _ curb. So module is used to decrypt the corresponding ing password for Kerberos authentication. IfPam_ Password ing cannot be performed if the password required by the Unix. So module fails to pass verification.PamThe next authentication module is called without prompting the user to enter the Kerberos password. The option of the last module is use_first_pass, soPamThe _ 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.
Linux-PamIt is a flexible and powerful user identification mechanism. This article analyzes its composition structure and the relationship between each part.Pam.