Summary of PAM module learning under Linux

When executing some programs in Linux, these programs must first authenticate the user who initiated it before executing, such as login, Su, etc. The authentication process for identity or status in Linux is performed by Pam , and Pam (pluggable authentication Modules) dynamically loads the validation module, as it is possible to dynamically change the contents of the validation as needed. Therefore, the flexibility of verification can be greatly improved.

I. Introduction of PAM Module

Linux-pam (i.e. Linux pluggable authentication module) is a set of shared libraries that allow local system administrators to choose the authentication method of the program at will. In other words, without (rewriting) recompiling an application that contains PAM functionality, you can change the authentication mechanism it uses, even if you upgrade the local authentication mechanism without modifying the program.
Pam uses the files under configuration/etc/pam.d/to manage the authentication method for the program. The application invokes the appropriate configuration file, thereby invoking the local authentication module. The module is placed under/lib/security to load the dynamic library form, as we use the SU command, You will be prompted to enter the root user's password. This is what the SU command does by calling the PAM module.

Introduction to the configuration file of Pam

The PAM configuration file is written in the following two ways:
1) written in the/etc/pam.conf file, but in the system after CENTOS6, this file will not be.
2) The PAM configuration file is placed in the /etc/pam.d/ directory, its rule content is not included in the service section, that is, does not include the services name, and the/ETC/PAM.D directory under the name of the file is the service name. such as: Vsftpd,login, and so on, but less the leftmost service list. such as:/etc/pam.d/sshd

[Email protected] ~]# cat/etc/pam.d/sshd #%pam-1.0auth   requiredpam_sepermit.soauth       include      Password-authaccount    required     pam_nologin.soaccount    include      Password-authpassword   include      password-auth# pam_selinux.so Close should be the first session rulesession    required     pam_selinux.so      closesession    required     pam_loginuid.so# pam_selinux.so Open should only being followed by sessions to be exec Uted in the user contextsession    required     pam_selinux.so      open env_paramssession    required     Pam_namespace.sosession    Optional     pam_keyinit.so Force      revokesession    include      Password-auth

From the contents of the PAM module file above, the Pam configuration file can be divided into four columns ,

• The first column represents the module type
• The second column represents the control tag
• The third column represents the module path
• The fourth column represents the module parameters

1) First column: Pam's module type
The Linux-pam has four module types, representing four different tasks, namely:
Authentication Management (auth), account Management (accounts), Session Management (sessions) and password (password) management , one type may have multiple lines, They are called sequentially by the Pam module.

Further additions to the four types of modules are described below:
AUTH: The Authentication class interface module type is used to check the user and password, and to assign permissions;
This type of module provides two services for user authentication. Ask the application to prompt the user for a password or other token to confirm the legality of the user, and to set membership or other priorities through his credentials permission.

Account: Represents the user interface, mainly responsible for checking the legality of the account, to confirm whether the account expires, whether there is permission to login system, etc.;
This module performs an account management based on non-authentication. He is primarily used to restrict/allow users access to a service, the current system resources (up to how many users), and limit the user's location (for example, root can only be logged on through the console).

In most cases, the Auth and account are used together to limit the user's login and use of the service. Such restrictions would be more complete. For example, here is a specific example: login is an application. Login is going to do two things-first querying the user and then providing the user with the services they need, such as providing a shell program. Normally login requires the user to enter a name and password for authentication. When the user name is entered, the system will naturally be compared to whether the user is a legitimate user, whether it exists in a local or remote user database. If the account does exist, then whether it expires. These jobs are the responsibility of the account interface.

If the user satisfies the above sign-in precondition, whether it has the password to log on to the system, whether the password expires, and so on. The job is to be handled by the Auth interface, which usually encrypts the user password information and provides it to local (/etc/shadow) or remote (Ldap,kerberos, etc.) password authentication methods.

If the user is able to log in successfully, the work of Auth and account has been completed. But the entire validation process did not end completely. Because there are some other problems that are not confirmed. For example, how many windows can a user open at the same time on the server, how long the user will be able to use the terminal after logging in, what resources the user can access, what resources they cannot access, and so on. This means that subsequent authentication and environment definitions after login require additional interfaces. Here are the two sets of interfaces we will refer to below:

Session: Conversation class interface. Implementation of the session control from the user login success to exit;
Deal with things that need to be done before/after serving the user. Include: Turn on/off information for exchanging data, monitor directory, etc., set user session environment, etc. This means that this is the final pass before the system formally provides service.

Password: Password class interface. Controls the entire process of user password changes. That is, some of the information said to upgrade the user authentication token.

Note: when using the above interface, each line can specify only one type of interface, if the program requires a variety of interfaces, can be specified in multiple lines separately.

2) Second column: Pam's control mark

Pam uses a control tag to process and judge the return values of each module. (Only simple authentication marks are described here).

Specifies how to handle the results of the PAM module authentication, in short, to identify what happens after a successful or failed authentication, and how to control it. A single application can invoke a variety of underlying modules, often referred to as "stacking." corresponding to a program in the configuration file in the order in which all modules executed in the "heap", the status of each module in the heap and when the error is processed by the value of the Control_flag bar, his four possible values are required, requisite, sufficient or _optional:

Required: indicates that the success of the line and the module involved is a necessary condition for the user to authenticate. In other words, the program can pass authentication only if all of the modules that correspond to the application are successful with the required tag. Also, if any module with the required tag has an error, Pam does not immediately return the error message to the application, but instead returns the error message to the program that called him after all the modules have been called. Anyway, it's just that all the modules must be executed once, and any one of the module validation errors, the validation will continue, and the error message will not be returned until the execution is complete. The purpose of this is to not let users know which module they are rejecting and to protect system services in a covert way. Like setting up a firewall rule, the Deny class rule is set to drop, so that when the user is unsuccessful in accessing the network, it is not possible to determine exactly whether it is rejected or the target network is unreachable.

requisite: similar to required, only if the module with this tag returns successfully, the user can pass the authentication. The difference is that once it fails, the other modules that follow the heap are no longer executed, and the authentication process ends, and an error message is returned immediately. Compared with the above required, it seems to appear more aboveboard.

sufficient: indicates that the line and the validation of the module involved are sufficient conditions for the user to pass the identification. That is, whenever a module marked as sufficient succeeds, Pam returns a successful result to the application without having to try any other module. The same is true even if the subsequent cascading modules use the requisite or required control flags. When a module marked as sufficient fails, the sufficient module is treated as optional. Therefore, the configuration item with the sufficient flag bit does not cause the entire validation failure when the validation error is performed, but the door is open when the validation is successful. Therefore, the use of the control bit must be cautious.

Optional: He says the user can still pass the authentication even if the module validation failed for the line involved. In the PAM system, the module with the token fails to continue processing the next module. This means that even if the specified module fails validation, the user is allowed to enjoy the services provided by the application. Using this flag, the PAM framework ignores the validation errors generated by this module and continues the sequence of execution of the next cascading module.

include: represents the invocation of additional Pam profiles during validation. There are quite a number of applications in the RHEL system that implement authentication by fully calling/etc/pam.d/system-auth without having to re-write the configuration item. This also means that in many cases the user can log in to the system and be certified for the vast majority of applications.

There is also a more complex format for the syntax of value = action to set the control flags, which are separated by a space. The format is as follows:

value1 = Action1 value2 = Action2 ...

Where value can be the return value of the following Linux Pam libraries:
Success, Open_err, Symbol_err, Service_err, System_err, Buf_err, perm_denied, Auth_err, Cred_insufficient, Authinfo_ Unavail, User_unknown, Maxtries, NEW_AUTHTOK_REQD, acct_expired, Session_err, Cred_unavail, cred_expired, Cred_err, No_ Module_data, Conv_err, Authtok_err, Authtok_recover_err, Authtok_lock_busy, authtok_disable_aging, Try_again, ignore, Abort, authtok_expired, Module_unknown, Bad_item, and default.

The last (default) can be used to set the behavior that the above return value cannot express.

Actionn can be either a non-negative integer or one of the following tokens: Ignore, OK, done, bad, die, and reset. If the non-negative integer j, it is necessary to ignore the following J of the same type of module. In this way, the System Manager can more flexibly set up the Cascade module, the stack path of the module is determined by the response of a single module.

A detailed explanation of these marks:
Ignore: If a cascade module is used, the return value of the module will be ignored and will not be known by the application.
Bad: He says the return code should be seen as a sign that the module failed to validate. If this module is the first module to fail validation of the Cascade module, then his state value is the status value and result of the entire stack module validation.
Die: Terminates the cascading module validation process and returns to the application immediately.
OK: Tell Pam that the return value of this module will be used directly as the return value of all cascading modules. That is, if the module in front of the module returns a state of Pam_success, the return value overrides the previous return state. Note: If the return status of the previous module indicates that the module validation failed, then this return value cannot be overridden.
Done: Terminates verification of subsequent cascading modules and immediately returns control to the application.
Reset: Clears the return status of all cascading modules and restarts the validation from the next cascading module.

3) Module Path
The module path. That is, the location of the module to invoke. If it is a 64-bit system, generally saved in/lib64/security, such as: pam_unix.so, the same module, Can appear in different types. It performs different operations in different types. This is because each module, for different module types, has been programmed with various execution functions.

4) Module parameters
module parameters, which are parameters passed to the module. Parameters can have multiple, separated by a space, such as: Password required pam_unix.so Nullok obscure min=4 max=8 MD5.

Third, the PAM module working principle and process

For the Rhel system, for example, when Pam is installed, there are two major parts: the various Pam modules in the/lib/security directory and the PAM profiles that are already defined for various services and applications under the/ETC/PAM.D and/ETC/PAM.D directories. When an application with a certification requirement needs to be validated, the PAM profile that is responsible for its authentication is typically defined in the application. In vsftpd, for example, there is a line definition in its configuration file/etc/vsftpd/vsftpd.conf:

Indicates that authentication is performed based on the content defined by the/etc/pam.d/vsftpd file when logging in to an FTP server.

So, when the program needs authentication to find the relevant PAM configuration file, how is the authentication process done? Below we will explain by interpreting the/etc/pam.d/system-auth file.

The first thing to declare is: System-auth is a very important PAM configuration file, mainly responsible for user login system certification work. And the file is not only responsible for user login system authentication, other programs and services through the include interface can also call to it, thereby saving a lot of work to re-customize the configuration. So it should be said that the file is the system security master switch and the core PAM configuration file.

Here is the full contents of the/etc/pam.d/system-auth file:

[Email protected] ~]# grep-v ^#/etc/pam.d/system-authauth        required Pam_env.soauth      sufficient    PAM_ unix.so Nullok try_first_passauth        requisite     pam_succeed_if.so uid >= quietauth        required PAM_      Deny.soaccount     required      pam_unix.soaccount     sufficient    pam_localuser.soaccount     Sufficient    pam_succeed_if.so UID < quietaccount     required      Pam_permit.sopassword    Requisite     pam_cracklib.so try_first_pass retry=3 type=password    sufficient    pam_unix.so sha512 shadow Nullok try_first_pass Use_authtokpassword    required      pam_deny.sosession     optional      pam_ keyinit.so revokesession     Required      pam_limits.sosession     [Success=1 Default=ignore] Pam_succeed_ if.so service in Crond quiet use_uidsession     required      pam_unix.so

The first part indicates that when the user logs on, the user identity and password authentication are first identified through the Auth class interface. So in this process, validation passes through several configuration items with Auth.

The first step is to define the environment variables after user login through the pam_env.so module, Pam_env.so allows to set and change environment variables when the user logs on, by default, if no profile is specifically specified, it will be based on/ETC/SECURITY/PAM_ env.conf settings for environment variables after user logon.

Then through the Pam_unix.so module to prompt the user to enter a password, and the user's password and the password information recorded in the/etc/shadow, if the password is correct than the results will allow the user to log in, and the configuration item using the "sufficient" control bit, This means that as long as the validation of the configuration item passes, the user can fully authenticate without having to go to the following authentication. However, in special cases, the user is allowed to log on to the system with a blank password, for example, when a user is removed from the password field in/etc/shadow, the user can simply enter the user name to log in directly to the system.

In the following configuration item, the Pam_succeed_ If.so the user's sign-in conditions are limited to allow users with UID greater than 500 to log in with password Authentication, in the Linux system, the UID of the general system user is within 500, so the item is allowed to use the Useradd command and the default option established by the normal user directly from the local console login system.

Finally, through the pam_deny.so module, all the login requests that do not meet any of the above conditions are rejected directly, PAM_ Deny.so is a special module in which the return value of the module is always no, similar to the configuration guidelines for most security mechanisms, after all authentication rules have been completed, a request for a non-matching rule is rejected directly.

The three configuration items in the second section mainly indicate that the account's legitimacy and login rights are identified through the account class interface.

The first line still uses the Pam_unix.so module to declare that the user needs to pass the password authentication. The second line acknowledges the legality of system users with UID less than 500 in the system. The console is then open for all types of user logon requests.

The third chapter confirms the legality of the password or password used by the user through the password port alternative interface. The first line of configuration items represents the need to call Pam_cracklib to verify the user password complexity. If the user enters a password that does not meet the complexity requirement or the password is wrong, it will return a prompt for the password error after three of such errors, or any correct password validation during the period allows the login. It should be noted that pam_cracklib.so is a commonly used Pam module for controlling the complexity of passwords, and we will describe them in detail later. The two-line configuration items with pam_unix.so and pam_deny.so are then similar to the previous one. Indicates that a password authentication is required and that a login request that does not meet the requirements of any of the above configuration items is rejected directly. However, if the user performs a simple login, this configuration is not functional.

The Forth part will initialize the session connection for the user through session class interface. A few of the more important areas include the use of pam_keyinit.so to create a key ring for a user when they log in and revoke it when the user logs out. However, the control bits configured by the row use optional, indicating that this is not a requirement. The associated pam_limit.so profile is/etc/security/limits.conf, and by default there is no limit for each logged-on user by restricting the session connection resource when the user logs on by pam_limits.so. The configuration method for this module is described in detail later.

It can be seen that different applications use configuration files to invoke different Pam modules during the authentication process to customize the specific authentication process. It is not difficult to see, in fact, according to the actual needs of the PAM configuration files can be modified to meet different certification requirements, such as the following example:

#%pam-1.0# This file is auto-generated.# User changes would be destroyed the next time Authconfig is Run.auth required Pam_env.soauth required pam_tally.so Onerr=fail Deny=5auth sufficient Pam _unix.so Nullok Try_first_passauth requisite pam_succeed_if.so uid >= Quietauth required Pam_deny.soacco UNT required Pam_unix.soaccount sufficient pam_succeed_if.so UID < quietaccount required Pam_permit.sopasswo Rd Requisite pam_cracklib.so try_first_pass retry=3 minlen=10 lcredit=-1 ucredit=-1 dcredit=-1 ocredit=-1 difok=6passwo Rd Requisite pam_passwdqc.so Use_first_pass Enforce=everyonepassword sufficient pam_unix.so MD5 remember=6 shadow Nu Llok Try_first_pass Use_authtokpassword required pam_deny.sosession optional pam_keyinit.so revokesession requi Red Pam_limits.sosession [Success=1 Default=ignore] pam_succeed_if.so service in Crond quiet use_uidsession Requir Ed Pam_unix.so 

In this case, the restrictions on the complexity of user password modification, the locking limit after the user repeatedly entered the password, and the user's password history and other restrictions are added.

Therefore, we have increased the security requirements of user login verification to a large extent by modifying the above System-auth configuration file, increasing the module and changing the options. We'll explain the configuration in detail later in the article.

It is also important to note that the logical order of configuration items and module invocations is critical throughout the PAM configuration file. Because Pam is validated according to the order of the configuration items. The wrong sequence of module calls is likely to cause serious security problems or even system errors. It is important to consider this when modifying the PAM configuration.

Four, the common Pam module introduction

Pam Module	Combining management types	Description
Pam_unix.so	Auth	Prompts the user for a password and is compared to the/etc/shadow file. Match returns 0
	Account	Check the user's account information (including whether it expires or not). Returns 0 when the account is available.
	Password	Modify the user's password. Update the shadow file with the password that the user entered as the user's new password
Pam_shells.so	Auth Account	If the user wants to log into the system, then its shell must be one of the shells in the/etc/shells file
Pam_deny.so	Account Auth Password Session	This module can be used to deny access to
Pam_permit.so	Auth Account Password Session	The module will return to success at any time.
Pam_securetty.so	Auth	If the user wants to log on as root, the login TTY must be in/etc/securetty.
Pam_listfile.so	Auth Account Password session	Access to the control switch of the application process
Pam_cracklib.so	Password	This module can be inserted into a program's password stack to check the strength of the password.
Pam_limits.so	Session	The definition uses the upper limit of system resources, the root user is also subject to this limit, can be set by/etc/security/limits.conf or/etc/security/limits.d/*.conf

v. Example Description

1) pam_listfile.so
Only Kevin users can log in remotely via SSH. The procedure is as follows:

Add an article to the/etc/pam.d/sshd file:
Auth Required pam_listfile.so item=user sense=allow file=/etc/sshdusers onerr=succeed

Add two users Kevin and Grace

[[email protected] ~]# useradd kevin[[email protected] ~]# passwd kevin[[email protected] ~]# useradd Grace[[email Protect Ed] ~]# passwd Grace

Edit file specified files, add last user Kevin (this step is key)

[[email protected] ~]# echo "Kevin" >/etc/sshdusers          //file/etc/sshdusers is defined in the above add to/etc/pam.d/sshd

Then verify that the use of Kevin account can be normal SSH login, using grace account will not be normal SSH login!

[Email protected] ~]# ssh-p22 [email protected][email protected] ' s password:last login:thu Mar-12:02:18 2018 from 1 92.168.10.206[[email protected] ~]# ssh-p22 [email protected][email protected] ' s password:permission denied, please try Again. [Email protected] ~]# ssh-p22 [email protected][email protected] ' s password:permission denied, please try again.

Note: If Root is also connected remotely using SSH, it will also be subject to pam_listfile.so restrictions.

Warm tips:
If an error occurs, Linux-pam may change the security of the system. Depending on your choice, you can choose not to be secure (open system) and absolutely secure (deny any access). In general, linux-pam tend to the latter in the event of an error. Any configuration errors can cause the system to be inaccessible throughout or partially. When configuring Linux-pam, the most likely problem you may encounter is that the Linux-pam profile/etc/pam.d/* is deleted. If such a thing happens, your system will be locked. There are ways to recover, the best way is to use a backup image to restore the system, or log into the single user mode and then make the correct configuration.

2) Disable the use of the SU command to switch between accounts

Disadvantages of Su
1) Unsafe SU tools in multi-participant system management, is not the best choice, su only for one or two people to participate in the management system, after all, SU does not allow ordinary users limited use; Root password should be in the hands of a small number of users.
2) Trouble: The root password needs to be told to each person who needs root permission.

You can set the prohibit user to use the SU command in the/etc/pam.d/su file.
[Email protected] ~]# VIM/ETC/PAM.D/SU
Auth sufficient pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth Sufficient pam_wheel.so Trust Use_uid
# Uncomment the following line to require a user to being in the "wheel" group.
#auth Required Pam_wheel.so Use_uid

The two lines above are the default (that is, opening the first line, commenting on the second line), This state allows all users to switch between using the SU command! (or both lines are commented and run all users can use the SU command)
If you turn on the second line , which means that only users within the root user and wheel group can use the SU command.
if the first line is commented , the second line is turned on, indicating that only users within the wheel group can use the SU command, and the root user is also disabled by the SU command.

Summary of PAM module learning under Linux