Shulou(Shulou.com)06/02 Report--

What is Linux-PAM

For the sake of security, the computer system can only be accessed by authorized legitimate users. Here, how to correctly identify the true identity of users is a key problem. The so-called user authentication is the process that the user submits his identity certificate to the system in a secure way, and then the system confirms whether the user's identity is true or not. In other words, user authentication is the portal of the system, and every user entering the system must go through the level of authentication.

Initially, the user authentication process of the Linux system is the same as that of various Unix systems: the system administrator sets up an account for the user and assigns him a password, and the user logs in with the specified password and resets his own password, so that the user has a secret password that only he knows. In general, the user's password is encrypted and stored in the / etc/passwd file. When the user logs in, the login service program prompts the user to enter his user name and password, then encrypts the password and compares it with the secret password of the corresponding account in the / etc/passwd file. If the password matches, the identity of the user is true and the user is allowed to access the system. This idea is based on the fact that only the user knows his password, so if the password entered is correct, then the system assumes that he is the claimed person.

Later, many other methods are used to authenticate users, such as Kerberos for network environment and authentication system based on smart card. But there is a common problem with these authentication schemes: the code that implements the authentication function is usually compiled together as part of the application, so the problem arises-if you find that the algorithm is flawed or want to use another authentication method, the user has to rewrite (modify or replace) and then recompile the original program. Obviously, our original identification scheme is inflexible, and the situation here is very exasperating.

In view of the above reasons, people begin to look for a better alternative: on the one hand, separate the authentication function from the application and carry out modular design, implementation and maintenance; on the other hand, establish a standard API for these authentication modules, so that each application can easily use the various functions they provide; at the same time, the authentication mechanism is transparent to its upper users (including applications and end users). Until 1995, SUN researchers proposed a scheme 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. The plug-in authentication module (PAM) mechanism adopts modular design and plug-in functions, so that we can easily insert new authentication modules or replace original components in the application without any modification to the application, thus making it easier to customize, maintain and upgrade the software-because the authentication mechanism is relatively independent from the application. Applications can easily use the various authentication functions provided by PAM through PAM API without having to know too many underlying details. In addition, PAM is also easy to use, mainly in that it shields the details of authentication from the upper layer, so users are not forced to learn various authentication methods and do not have to remember multiple passwords And because it realizes the integration of multiple authentication mechanisms, a single program can easily integrate multiple authentication mechanisms, such as Kerberos authentication mechanism and Diffie-Hellman authentication mechanism, but users can still log in with the same password without feeling that different authentication methods have been adopted.

Under the efforts of the majority of developers, various versions of the UNIX system have provided support for PAM. Among them, Linux-PAM is specifically implemented for Linux machines, including Caldera 1.3,2.2, Debian 2.2, Turbo Linux 3.6, Red Hat 5.0and SuSE 6.2 and their subsequent versions all provide support for PAM. FreeBSD has supported PAM since version 3. 1. It should be noted that, except for the specific implementation, the framework of PAM on all versions of Unix systems is the same, so the knowledge of the Linux-PAM framework we introduce here is universal. So as we can see in the process of introducing its framework below, we do not deliberately distinguish between the terms PAM and Linux-PAM.

Second, the hierarchical architecture of PAM

In order to achieve its plug-in function and ease of use, PAM adopts a hierarchical design idea: let each authentication module be independent from the application, and then use PAM API as the link between the two, so that the application can flexibly "insert" the required authentication function module according to the need, thus truly realize the "authentication function, on demand". In fact, this idea is very much in line with the important idea of "high cohesion, low coupling" in software design. The architecture of PAM is shown in the following diagram:

Figure 1 PAM architecture

As can be seen from the above figure, PAM API acts as a connecting link between the application and the authentication module: when the application calls PAM API, the application interface layer loads the corresponding authentication module according to the provisions of the configuration file pam.conf. Then the request (that is, the parameters obtained from the application) is passed to the underlying authentication module, and the authentication module can perform specific authentication operations according to the requirements. When the authentication module performs the corresponding operation, the result is returned to the application interface layer, and then the reply from the authentication module is returned to the application according to the specific configuration.

The above describes the various components of PAM and how they operate as a whole. The key lower layers of PAM are described below.

Third, the first layer: module layer

The module layer is at the bottom of the whole structure, and it provides services such as user authentication for the interface layer, that is to say, all the specific authentication work is done by the modules of this layer. For applications, some require not only to verify the user's password, but also to verify that the user's account has expired. In addition, some applications may require recording information about the current session or changing passwords, etc., so PAM not only provides authentication modules in the module layer, but also provides modules that support account management, session management and password management functions. Of course, these four modules are not necessary for all applications, but are flexible according to needs. For example, while login may require access to all four modules, su may only need to use authentication components. As for how to choose, it involves the PAM API and configuration files of the interface layer, which will be described below.

Fourth, the second layer: application interface layer

The application interface layer is located in the middle part of the PAM structure, which shields the specific details of the user authentication process for the application, and provides specific services to the specific modules in the module layer. As you can see from figure 1, it mainly consists of PAM API and configuration files, which are described one by one below.

PAM API can be divided into two categories, one is the interface used to call the lower-level specific module, and this kind of interface corresponds to the underlying module:

1. Authentication class interface: pam_authenticate () is used to authenticate the user, and pam_setcred () is used to modify the user's secret information.

two。 Account class interface: pam_acct_mgmt () checks whether the account held by the authenticated user has the right to log in to the system, and whether the account has expired.

3. Session class interface: includes pam_open_session () and pam_close_session () functions for session management and accounting.

4. Password class interface: includes pam_chauthtok () for modifying user passwords.

The second kind of interface usually does not correspond to the underlying module one by one, and their function is to provide support to the underlying module and to realize the communication between the application and the module. The details are as follows:

1. Administrative interface

Each set of PAM transactions starts with pam_start () and ends with the pam_end () function. The interfaces pam_get_item () and pam_set_item () are used to read and write state information related to PAM transactions. At the same time, you can use pam_str () to output the error message of the PAM interface.

two。 Communication interface between application program and module

During application initialization, some data such as user names can be stored in the PAM interface layer through pam_start () for future use by the underlying module. 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. Communication interface between user and module

The pam_start () function allows the underlying module to read and write authentication information related to the module through a conversational callback function, such as prompting the user for a password in the way specified by the application.

4. Communication interface between modules

Although the modules are independent, they can still share some common information related to the authentication session, such as user name, service name, password, and so on, through the pam_get_item () and pam_set_item () interfaces. In addition, these API can also be used to let the application modify the state information after calling pam_start ().

5. Interface for reading and writing module status information

The interfaces pam_get_data () and pam_set_data () are used to access and update information about a specific module as required by the PAM handle. In addition, you can attach a cleanup data function to these modules to clean up the site when pam_end () is called.

Because the PAM module is loaded on demand, the initialization task of each module is completed on the first call. If the cleanup tasks of some modules must be completed at the end of the authentication session, they should use pam_set_data () to specify the cleanup functions that will be called when the application calls the pam_end () interface.

V. configuration file

We notice that the configuration file is also placed in the application interface layer, which is used in conjunction with PAM API, thus achieving the purpose of flexibly inserting the required authentication module in the application. Its main function is to select the specific authentication module, the combination between modules and the behavior of the module for the application. The following is a sample configuration file:

Figure 2. Sample configuration file

We can see that the configuration file consists of many entries (one entry for each row), and each row is divided into five columns (one column for each column), which is explained in detail as follows:

In the first column, service represents applications that use PAM, such as login, passwd, rlogin, and so on. The OTHER in this column represents all applications that are not explicitly listed in the file. That is, if all programs have the same requirements, the entire configuration file needs only one line, and the first column of the line is OTHER. In this case, because all applications use the same session module, you can actually use a single line, that is

"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 ".

In the second column, module_type indicates the type of PAM underlying module used by the program: auth represents authentication module; account represents account class module; session represents session class module; password represents password class module. Note that only one type of module can be specified per line, and if the program requires multiple modules, it can be specified 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 is often called "stack". All modules executed according to the order of occurrence in the configuration file of a program become "heap". The status of each module in the heap and the handling of errors are determined by the value of the control_flag column. Its five possible values are required, Requisite, sufficient or _ stack, which are described below:

Required-- indicates that the success of the module is a necessary condition for the user to pass the authentication, in other words, the program can pass the authentication only after all the required tagged modules corresponding to the application are successful. At the same time, if there is an error in any module marked with required, PAM does not immediately return the error message to the application, but does not return the error message to the calling program until all modules have been called.

Requisite-- is similar to required, only after the module with this flag returns success, the user can pass authentication, except that if it fails, it no longer executes other modules later in the heap, and the authentication process ends here.

Optional-- indicates that even if the module fails, the user can still pass the authentication. In the PAM system, the module with this tag fails and continues to work on the next module.

Sufficient-- indicates that the success of the module is a sufficient condition for the user to pass authentication, that is, as soon as the module marked sufficient is successful, PAM immediately returns success to the application without having to try any other modules. When a module marked sufficient fails, the sufficient module is treated as an optional.

In the fourth column, module_path indicates the location of the PAM module.

In the fifth column, options is used to pass relevant options to a specific module, which is then interpreted by the module analysis. For example, use this column to turn on module debugging, or pass parameters such as timeout values to a module. In addition, it is also used to support the password mapping technology described below.

If an error occurs in either column, or if a module is not found, the line 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 authentication method of the ftp program, for example, we also use the UNIX password module for authentication, then we do not have to change the source program, we just need to change the

Ftp auth required pam_skey_auth.so debug

Change to

Ftp auth required pam_unix_auth.so debug

In this way, when the user uses ftp, the traditional UNIX password authentication method will be used to verify his identity. Thus, it is easy to change the authentication mechanism for applications under the PAM system. In addition, the stacking function of the PAM system also enables the application to support a variety of authentication mechanisms. For example, the login program in the following example has three entries related to authentication in the configuration file:

Figure 3. Sample configuration file

When the login program is executed, the pam_unix.so module (traditional UNIX password) is used to authenticate the user, then the pam_kerb.so module (Kerberos) is called to authenticate the user, and finally the pam_rsa.so module (RSA) is used to authenticate the user. In the process of authenticating users in the above order, if the pam_unix.so module authentication fails, it will continue to call the following module to authenticate instead of immediately returning an error message to the login program; the pam_kerb.so module handles it in the same way, and PAM does not return the previous error message to the login program until the last pam_rsa.so module is processed in sequence. For this configuration, even if the pam_rsa.so module passes smoothly, as long as there is an error between 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 both the pam_unix.so module and the pam_kerb.so module pass, the user can also pass the authentication.

VI. Password mapping

Using multiple authentication mechanisms on the same machine, especially when an application integrates multiple authentication mechanisms, may cause users to remember multiple passwords, which can make users feel uncomfortable. Although it is possible for all mechanisms to use the same password for ease of use, this weakens the security of the system-- if the password for any of these mechanisms is compromised, all mechanisms will be affected. In addition, different authentication mechanisms may have their own unique requirements in terms of password length, allowable characters, update interval, validity period and so on. These requirements are also a problem that must be considered for multiple authentication mechanisms to use the same password.

PAM provides us with a solution that does not rule out sharing a password for all authentication mechanisms while allowing each mechanism to use a different password through password mapping technology. The scheme encrypts other "secondary passwords" with the user's "master password" and stores these encrypted secondary passwords in a place where the user can access them. Once the master password has been verified, the authentication module can use it to decrypt those encrypted secondary passwords to obtain the corresponding password, and then pass the required password to the authentication module. This is called "password mapping". If there is an error in the password mapping, or if the mapping does not exist, each authentication module should prompt the user for a password. To support password mapping, the master password should be stored in the second layer of the PAM and provided by it to each authentication module on the stack when needed. At the same time, the password is cleared before the pam_authenticate function returns. In order to ensure the security of password mapping, the master password must be strong enough to consider some effective measures, such as making it longer, diversifying the types of password characters and using mixed types of characters to form passwords.

How passwords are encrypted and stored depends entirely on the implementation: it can store encrypted subpasswords (also known as "mapping 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 a hidden danger of dictionary attack.

To implement password mapping, all authentication modules should support the following four mapping options, ∶

1. Use_first_pass ∶ means that when the module executes, it does not prompt the user for a password, but authenticates the master password that prompted the user to enter before the module as their common password. If the user fails to pass the authentication of the master password, the module does not prompt the user to enter the password. This option is generally used when the system administrator wants to force multiple modules with the same password.

2. Try_first_pass ∶ uses the same as use_first_pass except that it prompts the user for a password if the master password is incorrect.

3. Use_mapped_pass ∶ means to use password mapping technology to get a valid password for this module. In other words, when the module is executed, it does not prompt the user to enter the password, but uses the mapping password, that is, the secondary password of the module decrypted by the master password, as the password input of this module to verify. If the user fails to authenticate the master password before that, the module will not prompt for the password.

4. Try_mapped_pass ∶ uses the same as use_mapped_pass except that it prompts the user for a password if the master password is incorrect.

When passwords are changed, PAM saves all old and new passwords and makes them accessible to the relevant modules. Other modules can use this information to update the encrypted password without forcing the user to enter the password again.

Take the following configuration file as an example to explain password mapping:

Figure 4. 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 by entering the password 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. Then call the pam_kerb.so module, because the option of the module is use_mapped_pass, it will use the password mapping mechanism for authentication, that is, if the UNIX password authentication passes, it will be used as the main password of the pam_kerb.so module to decrypt its corresponding mapping password for Kerberos authentication. If the password required by the pam_unix.so module fails authentication, the password mapping cannot be performed, and the PAM will directly call the next authentication module without prompting the user for its Kerberos password. The option for the last module is use_first_pass, so the pam_rsa.so module will use the master password entered earlier to authenticate the user, and the user will not be prompted for the RSA password if the password is incorrect. Therefore, as long as the password entered for the first time is correct and the mapping password exists, one password is sufficient to pass authentication.

VII. Concluding remarks

Linux-PAM is a user authentication mechanism with flexible and powerful functions. This paper analyzes its composition and structure and the relationship between its parts, hoping to help readers understand the mechanism of PAM.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.