I. Pluggable verification module (PAM)
In the past, each program used its own method to authenticate the user. In Red Hat Enterprise Linux, most programs are configured to use a centralized user authentication method called Pluggable authentication module (pluggable authentication Modules) (PAM).
Pam uses a pluggable, modular structure. It provides a great flexibility for system administrators to set user authentication policies.
In most cases, the default Pam profile for a PAM-enabled application can meet the general requirements. However, in some cases, it is necessary to configure the PAM configuration file in a special configuration. Because if you configure Pam incorrectly, the security of the system may be compromised, So before you configure these files, you must have a certain understanding of the structure of these files.
two. Pam's Advantages
PAM offers the following advantages:
1. A common user authentication program that can be used by multiple applications.
2. Provides a great deal of flexibility for system administrators and application developers in authenticating user authentication.
3. Includes a single library with detailed documentation that allows developers to not develop their own user authentication systems.
three. Pam configuration file
The previous Pam version uses the/etc/pam.conf file, but now the file is obsolete and is used only when the/etc/pam.d/directory does not exist. Each PAM-enabled application or service is/etc/pam.d/ There is a corresponding file in the directory. The name of each file in this directory is the same as the name of the service to which they control access. PAM-enabled applications need to define their service names and install their own Pam profiles in the/etc/pam.d/directory. For example, The login program defines its service name login and installs the/etc/pam.d/login configuration file.
Each PAM configuration file includes a set of commands in the following format:
The specific explanations are as follows:
A. Modular interface (module Interface)
There are currently four classes of available Pam module interfaces, each representing different aspects of user authentication:
Auth, this module interface is used for authentication. For example, it requires a password and verifies that the password is correct. A module with this interface can also set up licenses, such as group members or Kerberos tokens.
Account, this module interface is used to verify the permitted access. For example, check whether a user accounts have expired, or whether a user is allowed to log on at a specific time of day.
Password, this module interface is used to change the user's password.
Session, this module interface is used to configure and manage user sessions. Modules with this interface can also perform additional tasks required to allow access, such as mounting the user's home directory to make the user's mailbox valid.
B. Controlling flag (Control flag)
All PAM modules produce a successful or unsuccessful result after being called. The control flag will instruct Pam what to do next. The module can be stacked in a specific order, controlling the flag to determine the importance of a particular module to the user to verify the success or failure of the entire process.
There are four pre-defined control flags:
Required, for the verification process to continue, the result of this module must be successful. If this step of the test fails, the user will not be notified immediately, they will be notified when all modules are completed.
Requisite, to enable validation to proceed, the result of this module must be successful. However, if the test fails, the user will be notified immediately, and the notification information includes the first failed required or requisite module test.
Sufficient, if the module fails validation, the result will not be ignored. However, if a module identified as sufficient succeeds and no previous module authentication fails that is identified as required, then the user is authenticated to use the service. No additional validation results are required.
Optional, the module results are ignored. Modules identified as optional are only necessary for validation to succeed if no other modules are referenced in this interface.
C. Modules name (module name)
The module name, Pam, provides the name of an pluggable module that includes a specific module interface. In older versions of Red Hat Enterprise Linux, the PAM configuration file includes the full path of the module. But since the Multilib system was used (it stores the 64-bit PAM module in the/lib64/security/ ), the directory name can be omitted, the application will be connected to the appropriate version of Libpam, it can locate the correct version of the module.
D. Module parameters (Modules Arguments)
When validating some modules, Pam uses parameters to pass the information to an pluggable module.
For example, the Pam_userdb.so module uses the information stored in a Berkeley db file to authenticate the user. Berkeley db is an open-source database system that is built into many applications. This module uses a DB parameter to make the Berkeley DB knows which database is used by the requested service. The following is a typical pam_userdb.so line in a PAM configuration. is the full path to the Berkeley DB database file:
Auth Required pam_userdb.so db=
Invalid parameters are usually ignored and do not affect the results of the PAM module validation. However, in some modules, invalid parameters can cause module validation to fail. Most modules will write errors to the/var/log/secure file.
Here is an example of a PAM application configuration file:
#%pam-1.0
Auth Required pam_securetty.so
Auth Required pam_unix.so Nullok
Auth Required pam_nologin.so
Account Required Pam_unix.so
Password Required pam_cracklib.so retry=3
Password Required pam_unix.so Shadow Nullok Use_authtok
Session Required Pam_unix.so
The first line is the comment line, which is indicated by the well font number (#) at the beginning of the line.
Auth Required pam_securetty.so, this module guarantees that if a user attempts to log on as a root user, the TTY logged in by this user needs to be listed in the/etc/securetty file if the file exists. If the TTY is not listed in this file, Any attempt to log in as the root user will fail with a login incorrect message displayed.
Auth Required pam_unix.so Nullok, this module requires the user to enter a password, and then uses the information stored in the/etc/passwd and/etc/shadow files (if the file exists) to check the user's input password. Nullok Parameter tells the pam_unix.so module to allow a blank password.
Auth Required pam_nologin.so, this is the final step of verification. This step checks to see if the/etc/nologin file exists. If the file exists and the user is not a root user, user authentication will fail.
(Note: In this example, all three auth are checked, even if the first auth module fails.) This prevents the user from knowing which step caused the validation failure. If a malicious network user knows this information, it can be used to attack the network.
Account required pam_unix.so, this module performs all required accounts validation. For example, if you enable the shadow password, the Pam_unix.so account interface checks whether the account has expired, or if the user has changed the password during the allowed transition period .
Password Required pam_cracklib.so retry=3, if a password has expired, the password portion of the Pam_cracklib.so module will require a new password. Then, It checks whether the newly created password can be easily cracked by the password dictionary hack system. The retry=3 parameter specifies that if the first test fails, the user will have another two chances to create a more secure password.
Password Required pam_unix.so Shadow Nullok Use_authtok, this line specifies that if the program wants to modify the user's password, you should use the PAM_ The password interface of the Unix.so module. The shadow parameter tells the module to create a shadow password when updating a user's password. The Nullok parameter tells the module to allow the user to change their password from a blank password to another password, otherwise, A no-password status is considered an account lock. Use_authtok provides a good example of the importance of the order in which the PAM module is stacked. This parameter tells the module not to ask the user for a new password, and it uses the password obtained from the previous password module. In this case, All new passwords must be checked by pam_cracklib.so before they are accepted.
Session Required pam_unix.so, the last line tells the Pam_unix.so module to manage the session interface. This module logs the user name and service type to the/var/log/at the beginning and end of each session Secure file. This module can be stacked with other session modules to implement other functions.
Four. Creating the PAM Module
New PAM modules can be created or added at any time for PAM-enabled applications.
For example, a program developer can create a one-time password generation method, and write a PAM module to support it. PAM-enabled applications can immediately use this new module without having to recompile. This allows program developers and system administrators to test various user authentication methods for different applications without having to recompile.
The documentation for the module is included in the/usr/share/doc/pam-/directory, where it is the version number of the PAM on the system.
Five. Pam and manage user identity cache (Administrative credential Caching)
A set of graphical management tools included in Red Hat Enterprise Linux provides users with administrative rights for a period of time (up to 5 minutes) through the pam_timestamp.so module. It's important to understand how they work, and if a user leaves their terminal temporarily, PAM_ Timestamp.so is not shut down, so anyone who can use this terminal can use it to manipulate the system.
In Pam Timestamp (timestamp) planning, the graphical hypervisor requires the user to enter the root user password at startup. When the user is authenticated, the Pam_timestamp.so module creates a timestamp file. By default, it will be in the/var/run/sudo/ The directory is created. If the timestamp file already exists, the graphical hypervisor no longer asks for a password. The pam_timestamp.so module updates the timestamp file, which allows the user to regain administrative access for an additional 5 minutes.
You can verify the actual state of the timestamp file by checking the/var/run/sudo/file. For desktops, the relevant file is unknown:root. If the file exists and its timestamp is not longer than 5 minutes, the user identity is valid.
When a timestamp file exists, a validation icon appears in the notification area of the system panel.
Close the console of the PAM where the timestamp is active, preferably destroying the timestamp file. To perform this task in a graphical environment, click the Verification icon in the Panel. A dialog box appears, click "Forget Authorization" to destroy the active timestamp file.
You should be aware of the following issues when working with PAM timestamp files:
1, if you telnet to the system by using SSH, use the/sbin/pam_timestamp_check-k root command to destroy the timestamp file.
2, the/sbin/pam_timestamp_check-k root command should be run under the same terminal window that issued the use of this privileged application.
3, to use the/sbin/pam_timestamp_check-k command, you must be logged in as the user who originally started the pam_timestamp.so module. Do not log on as root to use this command.
4, if you want to destroy the user identity information on the desktop (instead of running forget Authorization in the icon), you can use the following command:
/sbin/pam_timestamp_check-k Root/dev/null 2>/dev/null
If you fail to use this command, you will only remove the user identity information from the pty of the command you are running.
Common Pam_timestamp Commands
Timestamp_timeout that specifies the validity period (in seconds) of the timestamp file. The default value is 300 seconds (5 minutes).
Timestampdir, specifies in which directory the timestamp file is saved. The default value is/var/run/sudo/.
Six. Pam and device owner
In Red Hat Enterprise Linux, the first user to log on through a physical console can control a specific device and perform tasks that are typically only root users can perform. This is controlled by the PAM module named Pam_console.so.
When a user logs on to a Red Hat Enterprise Linux system, the Pam_console.so module is called by login or the graphical login program (GDM,KDM and XDM). If this user is the first user to log in through a physical console--called a console user-- The module assigns ownership of some of the devices that the usual owner is the root user to. This console user will have these devices until the end of the last local session of the user. After the user exits the system, the owner identity of the devices is returned to the root user.
These devices include, but are not limited to, sound cards, floppy and CD-ROM drives.
This facility allows a local user to use these devices without the need for root privileges, thus simplifying the program for the console user to accomplish some common tasks.
You can modify the list of devices controlled by Pam_console.so by editing the following files:
1./etc/security/console.perms
2./etc/security/console.perms.d/50-default.perms
You can modify the access rights for the different devices listed in the file above, or override the default settings that you have specified. You can create a new file (such as xx-name.perms) and enter the values you want to modify. It is best not to directly modify the 50-default.perms file. The file name of the new default file must start with a value greater than 50, such as 51-default.perms. This overrides the default value of the 50-default.perms file.
If the configuration file for GDM,KDM or XDM has been modified to allow remote users to log on, and the host is configured to use Run Level 5, it is recommended that the value of the/etc/security/console.perms file and the command entry be changed to:
=tty[0-9][0-9]* vc/[0-9][0-9]*: 0\. [0-9]: 0
=:0\. [0-9]: 0
This prevents remote users from gaining access to the device and restricting their use of the application on that machine.
If the configuration file for GDM,KDM or XDM is modified to allow remote users to log on, and the host is configured to use a runlevel other than RunLevel 5, it is recommended that you delete the entire command and change the command to:
=tty[0-9][0-9]* vc/[0-9][0-9]*
Seven. Pam and application Access
The console user can also use some of the programs that are configured for the user in the/etc/security/console.apps/directory.
This directory includes configuration files that allow console users to use certain applications in/sbin and/usr/sbin.
These configuration files have the same name as the application that they set.
A set of important application programs that the console user can use includes three programs that can be used to shut down or restart the system:
/sbin/halt
/sbin/reboot
/sbin/poweroff
Because these are PAM-enabled applications, you can call the Pam_console.so module when needed.
Eight. Additional resource information
The man page associated with Pam.
Pam, which describes the important information of Pam, including the structure and purpose of the PAM configuration file.
Note: This page discusses a variety of individual profiles in the/etc/pam.conf and/etc/pam.d/directories. By default, Red Hat Enterprise Linux uses a variety of individual profiles under the/etc/pam.d/directory instead of/etc/pam.conf, Even if this file exists also used.
Pam_console, describes the purpose of the Pam_console.so module, and also describes the appropriate syntax that should be used in the PAM configuration file.
Console.apps, describes the format of the/etc/security/console.apps configuration file and the available options, which specify which applications can be accessed by the console user assigned by Pam.
Console.perms, describes the format of the/etc/security/console.perms configuration file and the available options, and specifies the console user rights assigned by Pam.
Pam_timestamp, describes the pam_timestamp.so module.
Pluggable authentication Module (PAM) Overview (reproduced)
