Are you using the advanced security authentication mechanism in Linux?

Linux is a multi-user, multi-process operating system. It provides many system and network services for users. Therefore, from the application perspective, it inevitably requires security authentication for a large number of applications and their users, only users who have passed the Security Authentication can reasonably and legally use the corresponding system and network services. PAM is a very mature security authentication mechanism that can provide secure and reliable authentication services for multiple Linux applications. This article describes the principles, configurations, and applications of the PAM mechanism in detail. Users can use this technology efficiently to ensure the security of Linux systems.

1 PAM Authentication Mechanism Overview

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.

The embedded Authentication Module (PAM) mechanism adopts modular design and plug-in functions, so that we can easily Insert new authentication modules 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. Linux-PAM (Pluggable Authentication Modules for Linux) is specially implemented for Linux operating systems, including Debian Linux 2.2, Turbo Linux 3.6, Red Hat Linux 5.0, and SuSE Linux6.2 and their subsequent versions all provide support for PAM. FreeBSD supports PAM from version 3.1. Note: apart from the specific implementation, the PAM frameworks on Unix systems of different versions are the same. Therefore, the Linux-PAM framework knowledge introduced in this article is universal.

2 Linux-PAM Configuration

Linux-PAM aims to provide system managers with maximum flexibility. The system administrator can configure Linux-PAM in two ways: A single configuration file/etc/pam. conf or the/etc/pam. d/directory. Next we will discuss the syntax of the configuration file, and give some practical examples for your reference.

2.1 Linux-PAM single Configuration File Syntax

As shown in figure 1, you may notice that the configuration file is also placed in the application interface layer, which 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.

Before using this configuration file, you should first understand that the Linux-PAM mark is case sensitive. There are two special symbols: "#" and ".". The comment in the configuration file starts with #. Generally, each line in the configuration file is an entry (except for the comment). However, if a certain entry has a long definition, you can use an escape character to return to the line, the next row is also seen as part of this entry.

The format of each line in the/etc/pam. conf file is as follows:

Service-name module-type control-flag module-path arguments

The specific meanings of each character segment are as follows:

Service-name: name of the service allocated to this entry. This is usually the session name of the given application. For example, ftpd, rlogind, and su. Linux-PAM also reserves a special service name for the default authentication mechanism, namely ohter, which can be case sensitive. In addition, if a module specifies a service named after it, other should be ignored.

Modle-type: Linux-PAM currently has four types of modules:

Auth: This type of module provides two services for user verification: asking the application to prompt the user to enter a password or other mark to confirm the validity of the user; using its credential to permit permissions, set group members or other priorities.

Account: This type of module performs non-verified account management. It is mainly used to limit/allow users to access a service, the current effective system resources (up to how many users can have), and limit the user location (for example: root users can only log on from the console ).

Session: This type of module is mainly used to process the tasks that need to be done before/after the service is provided to users, including recording information on opening/closing data and monitoring directories.

Password: Used to upgrade the user verification mark.

Control-flag: the control flag is used to set the response required by PAM after verification is successful or fails. Because modules can be stacked, the control mark can determine the importance of each module. The application will not realize the success or failure of a single module, but will only receive the comprehensive response information of the Linux-PAM library's success or failure.

The execution sequence of the cascade module depends on the entry sequence of the/etc/pam. conf file. The module before the entry column is executed first. From Linux-PAM 6.0, you can use two types of syntax to define the control flag. One simple way is to use a single keyword to define the control flag. There are four such keywords: required, requisite, sufficient, and optional. Linux-PAM explains these keywords in the following way:

Required: indicates that even if a module fails to verify the user, PAM returns an error message after all modules are executed. This is done to prevent users from knowing which module is rejected. If the user is successfully verified, all modules return the success message.

Requisite: if a specific module fails to verify the user, PAM immediately returns an error message, returning the control to the application, and no longer performing verification on other modules.

Sufficient: indicates that if a user passes the verification of this module, the PAM structure immediately returns the verification success information, and the control is applied to the application. Even if the requisite or required control flag is used, the subsequent cascade modules will not be executed. If the verification fails, sufficient works the same way as optional.

Optional: allows users to enjoy the services provided by the application even if the verification of the specified module fails. With this flag, the PAM framework ignores the verification errors generated by this module and continues to execute the next cascade module in sequence.

Module-path: path of the PAM verification module. If it starts with a slash (/), it indicates the complete path. If it is not followed by a slash (/), it indicates the relative path relative to/usr/lib/security.

Args: The parameter passed to the module. Similar to common Linux Shell Command Line parameters. Valid parameters include some common parameters and parameters specific to the given module. Invalid parameters are ignored, and error messages are recorded in syslog.

Note: Any row of errors in the configuration file will result in verification failure and related error messages will be recorded in syslog.

A simple example is as follows:
Login auth required pam_unix.so debug
Login auth required pam_kerb.so use_mapped_pass
Login auth optional pam_rsa.so use_first_pass

In this way, when the login program is executed, the pam_unix.so module is used to identify users using the traditional UNIX Password method, and then the pam_kerb.so module is called, that is, Kerberos, to authenticate users, 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.

Another example of ftp is as follows:
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 is worth mentioning that there are no ready-made/etc/pam in some Linux operating systems (such as Fedora. the conf file can be used. You need to generate and edit it as described in this section.

2.2 password ing mechanism

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.

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:

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 the password ing technology is used.