In Linux, PAM refers to the dynamically loadable verification module. It is a set of shared libraries that allow local system administrators to choose the authentication method of the program at will; because the verification content can be dynamically changed as needed. , so the flexibility of verification can be greatly improved. PAM uses the configuration file under "/etc/pam.d/" to manage the authentication method of the program. The application calls the corresponding configuration file to call the local authentication module.
#The operating environment of this tutorial: linux7.3 system, Dell G3 computer.
When executing some programs in Linux, these programs must first authenticate the user who starts them before execution, and only allow execution after meeting certain requirements, such as login, su, etc. The identity or status verification process in Linux is performed by PAM, PAM (Pluggable Authentication Modules) can dynamically load the verification module, because the verification content can be dynamically changed as needed, so The flexibility of verification can be greatly improved.
1. Introduction to PAM module
Linux-PAM (linux pluggable authentication module) is a set of shared libraries that enable local system management Members are free to choose how the program is authenticated. In other words, you can change the authentication mechanism it uses without recompiling (rewriting) an application that contains PAM functionality. In this way, even if the local authentication mechanism is upgraded, the program does not need to be modified.
PAM uses the files under configuration /etc/pam.d/ to manage the authentication method of the program. The application calls the corresponding configuration file to call the local authentication module. The module is placed under /lib/security and loaded as a dynamic library. When we use the su command, the system will prompt you to enter the password of the root user. This is what the su command does by calling the PAM module.
PAM module types
Linux-PAM has four module types, which represent four different tasks. They are:
Authentication management(auth)
##Account management(account)
Session management(session)
Password management
A type may have multiple lines, which are called by the PAM module in sequence.
vi /etc/pam.d/system-auth
Copy after login
As shown below: The configuration is basically divided into four columns: module name, control, module library file and parameters.
The modules are mainly divided into four types. The specific functions are as follows:
auth module: used to identify the user's identity. For example: prompt the user to enter a password, or determine whether the user is root, etc.
auth module: Check various attributes of the account. For example: whether login is allowed, whether the maximum number of users has been reached, or whether the root user is allowed to log in from this terminal, etc.
session module: This module is used to define the operations to be performed before the user logs in and after the user logs out. Such as: login connection information, opening and closing of user data, mounting file systems, etc.
password module: Update with user information. For example: change user password.
Summary: auth, account, password, session, auth is an identifier, describing what to do, auth handles the verification during login, account, password, session and login It doesn't matter when verifying, for example, password is what handles changing the password.
2. PAM configuration file description
PAM configuration file has the following two ways of writing:1 ) is written in the /etc/pam.conf file, but in systems after centos6, this file no longer exists. 2) Place the PAM configuration file in the /etc/pam.d/ directory. Its rule content does not contain the service part, that is, it does not contain the service name, and /etc/pam. The name of the file in the d directory is the service name. Such as: vsftpd, login, etc., but the leftmost service list is missing. Such as: /etc/pam.d/sshd
[root@centos6-test06 ~]# cat /etc/pam.d/sshd
#%PAM-1.0
auth required pam_sepermit.so
auth include password-auth
account required pam_nologin.so
account include password-auth
password include password-auth
# pam_selinux.so close should be the first session rule
session required pam_selinux.so close
session required pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session required pam_selinux.so open env_params
session required pam_namespace.so
session optional pam_keyinit.so force revoke
session include password-auth
Copy after login
Judging from the contents of the pam module file above, we can divide the pam configuration file 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 module type Linux-PAM has four module types, representing four different tasks, they are: Authentication management (auth) , Account management (account) , Session management (session) and Password (password) management , a type may have multiple lines, they are in order In turn called by the PAM module.
Further explanation of the above four module types: auth: Indicates the authentication interface module type used to check users and passwords, and assign permissions; This type of module provides two services for user authentication. Let the application prompt the user for a password or other token to confirm the user's legitimacy; set group membership or other priorities through his credential permissions.
account: Represents the account class interface, mainly responsible for checking the legitimacy of the account, confirming whether the account has expired, whether there is permission to log in to the system, etc.; This kind of module Non-authentication-based account management is performed. It is mainly used to limit/allow users to access a certain service, current effective system resources (maximum number of users), and limit user location (for example: root can only log in through the console).
In most cases, auth and account are used together to restrict users' login and use of services. Such restrictions would be more complete. For example, the following is a specific example: login is an application. Login has to complete two tasks - first query the user, and then provide the user with the required services, such as providing a shell program. Usually Login requires the user to enter a name and password for verification. When the user name is entered, the system will naturally compare whether the user is a legitimate user and whether it exists in the local or remote user database. If the account does exist, will it expire? These tasks are handled by the account interface.
If the user meets the above login prerequisites, then whether it has a password that can log in to the system, whether the password has expired, etc. This work is handled by the auth interface, which usually encrypts user password information and provides it to local (/etc/shadow) or remote (ldap, kerberos, etc.) password verification methods for verification.
If the user can log in successfully, it proves that the work of auth and account has been completed. But the whole verification process is not completely over. Because there are some other issues that have not been confirmed. For example, how many windows can the user open on the server to log in at the same time, how many terminals can the user use after logging in for how long, what resources can and cannot be accessed by the user, etc. In other words, subsequent verification and environment definition after login also require other interfaces. These are the two sets of interfaces we will mention below:
session: session class interface. Implement session control from successful user login to exit; handle some things that need to be done before/after providing services to users. Including: turning on/off exchange data information, monitoring directories, etc., setting user session environment, etc. In other words, this is the last step before the system officially provides services.
password: Password class interface. Control the entire process of users changing passwords. This is what some information calls upgrading the user verification mark.
Note: When using the above interface, only one interface type can be specified in each line. If the program requires multiple interfaces, it can be specified in multiple lines. be stipulated separately.
2) Second column: PAM control tags
PAM uses control tags to process and determine the return value of each module. (In This only describes the simple certification mark).
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth required pam_tally.so onerr=fail deny=5
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so
account required pam_unix.so
account sufficient pam_succeed_if.so uid < 500 quiet
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 minlen=10 lcredit=-1 ucredit=-1 dcredit=-1 ocredit=-1 difok=6
password requisite pam_passwdqc.so use_first_pass enforce=everyone
password sufficient pam_unix.so md5 remember=6 shadow nullok try_first_pass use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
Copy after login
In it, there are added restrictions on the complexity of user password modifications, lock restrictions after the user enters the password incorrectly multiple times, and user password history and other restriction options.
So by modifying the above system-auth configuration file, adding modules and changing options, we have increased the security requirements for user login verification to a great extent. We will explain this configuration in detail in a later article.
In addition, it must be noted that in the entire PAM configuration file, the logical sequence of configuration items and module calls is very critical. Because PAM performs verification according to the order of configuration items. Incorrect module calling sequence may cause serious security problems or even system errors. So be sure to consider this when modifying the PAM configuration.
4. Introduction to commonly used PAM modules
PAM module
Combined management Type
Description
##pam_unix.so
auth
Prompts the user for password, And compare it with the /etc/shadow file. The match returns 0
account
Check the user's account information (including whether it has expired, etc.). The account is available When, return 0.
password
Modify the user's password. Update the shadow file with the password entered by the user as the user's new password
pam_shells.so
authaccount
If the user wants to log in to the system, then its shell must be in /etc/ shell
pam_deny.so
accountauthpassword
# in one of the shells files ##session
This module can be used to deny access
pam_permit.so
auth
account
password
session
The module returns success at any time.
pam_securetty.so
auth
If the user wants to log in as root, the logged-in tty must be in /etc/securetty.
pam_listfile.so
auth
account
password session
Control switch for accessing the application
pam_cracklib.so
password
This module can be inserted into the password stack of a program and used to check the strength of the password.
pam_limits .so
session
Define the upper limit of system resource usage. The root user will also be subject to this restriction. It can be passed through /etc/security/limits.conf or /etc/security/limits.d/ *.conf to set
[root@centos6-test06 vsftpd]# cat /etc/vsftpd/user_list
# vsftpd userlist
# If userlist_deny=NO, only allow users in this file
# If userlist_deny=YES (default), never allow users in this file, and
# do not even prompt for a password.
# Note that the default vsftpd pam config also checks /etc/vsftpd/ftpusers
# for users that are denied.
........
........
If you comment out this line of configuration, you will find that you are still required to enter a password even when switching to ordinary users as the root user.
Another method is to change the above "sufficient" to "required". Because of this, passing the verification of the pam_rootok.so module has become one of the necessary conditions.
Another application of the pam_rootok.so module is in the chfn command. The Chfn command is used to change the user description field in /etc/passwd. When executing the chfn command as root to modify user information, you do not need to enter a password. However, when executing chfn as a normal user, you need to enter a password before you can change your user description. This is actually the result of calling pam_rootok.so in the first line of the /etc/pam.d/chfn configuration file.
However, even if the first line in the configuration is commented out, the root user still does not need to use a password when modifying his information through chfn. So I'm afraid the effect is not very obvious. The main reason is that many PAM modules do not impose restrictions on the root user.
Example description (disable the su switching command between users):
Disadvantages of su 1) The unsafe su tool is not the best choice in system management involving multiple people. su is only suitable for systems where one or two people participate in management. After all, su cannot allow ordinary users to use it in a restricted manner; The superuser root password should be in the hands of a few users. 2) Trouble: The root password needs to be informed to everyone who needs root privileges.
You can set it in the /etc/pam.d/su file to prohibit users from using the su command [root@centos6-test06 ~]# 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 be in the "wheel" group. #auth required pam_wheel.so use_uid ..........
a) The two lines marked in red above are the default state (i.e. open the first line and comment the second line) , In this state, all users are allowed to interact Use the su command to switch! (Or if both lines are commented, all users can use the su command, but using su to switch to other ordinary users under root requires entering a password; if the first line is not commented, then root does not need to enter a password when using su to switch to ordinary users) b) If you open the second line , means that only the root user and those in the wheel group Only users can use the su command. c) If you comment the first line and turn on the second line, it means that only users in the wheel group can use the su command, root The user is also disabled from the su command.
5) pam_userdb.so module
The main function of the pam_userdb.so module is through a lightweight Berkeley database to store user and password information. In this way, user authentication will be performed through the database, instead of the traditional /etc/passwd and /etc/shadow or other types of network authentication based on LDAP or NIS. Therefore, users that exist in the Berkeley database are also called virtual users.
A typical use of the pam_userdb.so module is to configure an FTP server based on virtual user access in combination with vsftpd.
Compared with local users and anonymous users, virtual users are only useful users for the FTP server. These users are strictly limited to the pam_userdb database. Therefore, virtual users can only access the resources provided by the FTP server, which can greatly improve system security. In addition, compared to anonymous users, virtual users must use user names and passwords to access FTP resources. This also improves the manageability of downloads for FTP users.
[root@centos6-test06 ~]# cat /etc/pam.d/login|grep system-auth
auth include system-auth
account include system-auth
password include system-auth
session include system-auth
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
