This article is participating in the topic “Through Linux 30 years” essay activity

How to Configure and Use PAM in Linux. By Aaron Kili.

For a detailed understanding of Linux-PAM, you are advised to refer to The official Linux-PAM System Administrators’ Guide

Note: in the process of finding PAM related information, found this article, due to PAM information introduction is not much [found not much…👱♀️], and PAM understand it is really some challenges, some places are introduced are half-knowledge. This article gives a clear introduction to PAM’s overall structure, parameters, and configuration examples, which are helpful for understanding PAM and its use.

Of course, for a truly comprehensive understanding and use of Linux-PAM, The official Linux-PAM System Administrators’ Guide is recommended above.

introduce

Linux-pam (short for Pluggable Authentication Modules, derived from the UNIX-PAM architecture) is a powerful shared library for dynamically authenticating users to applications (or services) in Linux systems.

It integrates multiple low-level authentication modules into a high-level API to provide dynamic authentication support for applications. This allows developers to write applications that require authentication independently of the underlying authentication system.

Many modern Linux distributions support Linux-PAM (” PAM “) by default. In this article, you will explain how to configure advanced PAM on Ubuntu and CentOS systems.

Before we continue, please note:

  • As a system administrator, it is important to understand how the PAM configuration file defines the connection between the application (service) and the pluggable authentication module (PAM) that performs the actual authentication tasks. You don’t necessarily need to know the inner workings of PAM.

  • PAM has the potential to significantly change the security of Linux systems. Incorrect configuration may partially or completely disable access to the system. For example, accidentally deleting configuration files under /etc/pam.d/* and/or /etc/pam.conf could lock you out of your own system!

Check whether a Program supports PAM (How to Check a Program is PAM-Aware)

To use PAM, the application/program needs “PAM Aware”; You need to write and compile specifically to use PAM. To determine if a program is “pam-aware,” use the LDD command to check that it has been compiled with the PAM library.

Examples of checking SSHD:

$ sudo ldd /usr/sbin/sshd | grep libpam.so

	libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x00007effddbe2000)
Copy the code

How to Configure PAM in Linux

The main PAM configuration files are /etc/pam.conf and the /etc/pam.d/ directory that contains PAM configuration files for each pam-aware application/service.

If the /etc/pam.d/ directory exists, PAM ignores the /etc/pam.conf file.

The syntax of the master configuration file is as follows. The file consists of a series of rules written on a single line (the rules can be extended using the “” escape character), and comments are preceded by the “#” mark and extended to the end of the line.

The format of each rule is a space-delimited collection of tokens (the first three are case insensitive). We will explain these tags in a subsequent section.

service type control-flag module module-arguments 
Copy the code

Here:

  • Service: actual application name.
  • Type: module type/context/interface.
  • Control-flag: Indicates the behavior of PAM-API when a module fails in its authentication task.
  • Module: the absolute file name or relative pathname of PAM.
  • Module-arguments: Space-delimited list of tokens used to control module behavior.

The syntax of each file in the /etc/pam.d/ directory is similar to the syntax of the main file and consists of lines of the following form:

type control-flag module module-arguments
Copy the code

Here is an example of the rule definition (without module parameters) found in the /etc/pam.d/sshd file, which says that non-root logins are not allowed while /etc/nologin exists:

account required pam_nologin.so
Copy the code

Understanding PAM Management Groups and Control-flags

PAM authentication tasks are divided into four independent administrative groups. These groups manage different aspects of a typical user’s request for a restricted service.

A module is associated with one of the following management group types:

  • Account: provides the account authentication service: Does the user password expire? Does the user allow access to the requested service?
  • Authentication: Authenticates the user and sets the user credentials.
  • Password: responsible for updating the user password, and authentication module (authentication modules) Work together.
  • Session: Manages the operations performed at the beginning and end of a session.

PAM loadable object files (modules) are located in the following directories: /lib/security/ or /lib64/security, depending on the architecture.

The supported control-flags are:

  • Requisite: Immediately return control to the application, indicating that the module (modules) The nature of failure.Requisite — a necessary condition.
  • Required: LibPAM will not return success to the application until all required modules are successful. Required — required.
  • Sufficient: Assuming that all previous modules succeed, the success of the corresponding module causes the success to be returned to the application immediately (and the failure of the module is ignored).
  • Optional: The success or failure of the corresponding module is not recorded.

In addition to the above keywords, there are two other effective control flags:

  • Include: includes all lines of the given type from the specific configuration file that is used as the control representation parameter.
  • Substack: Contains all rows of the given type from the specific configuration file that represents the parameter for this control.

There are two lines of explanation in the original.

  • include: include all lines of given type from the configuration file specified as an argument to this control.
  • substack: include all lines of given type from the configuration file specified as an argument to this control.

How to Restrict Root Access to SSH Service Via PAM

As an example, we will configure how to use PAM to disable root user access to the system through SSH and login programs. Here, we disable the root user’s access to the system by restricting access to logins and SSHD services.

We can use the /lib/security/pam_listfile.so module, which provides a great deal of flexibility to restrict permissions to specific accounts.

Open and edit the target service file in /etc/pam.d/ as follows:

$ sudo vim /etc/pam.d/sshd
OR
$ sudo vim /etc/pam.d/login
Copy the code

Add the following rules to both files.

auth    required       pam_listfile.so \
        onerr=succeed  item=user  sense=deny  file=/etc/ssh/deniedusers
Copy the code

Explain each of the above positions:

  • Auth: is the module type (or context). — Module type (or context)

  • Required: is a control flag indicating that if a module is used, it must pass or the overall result will fail, regardless of the status of the other modules.

  • Pam_listfile.so: is a module that provides a way to deny or allow services based on arbitrary files.

  • Onerr =succeed: Indicates a module parameter.

  • Item =user: module parameter that specifies what is listed and should be checked in the file.

  • Sense =deny: module parameter that specifies the action to be taken if the action is found in the file and the opposite action if the item is not found in the file.

  • File = /etc/ssh/deniedUsers: module parameter specifying the file containing one item per line.

Next, we need to create the file /etc/ssh/deniedUsers and add the name root to it:

$ sudo vim /etc/ssh/deniedusers
Copy the code

Save the changes and close the file, then set the required permissions:

$ sudo chmod 600 /etc/ssh/deniedusers
Copy the code

From now on, the above rules will tell PAM to query the /etc/ssh/deniedUsers file and deny any listed users access to SSH and login services.

How to Configure Advanced PAM in Linux

To write more complex PAM rules, you can use the following form of control-flags:

type[value1 = action1 value2 = action2...].  module module-argumentsCopy the code

Where valueN corresponds to the return code of the function called in the module that defines the row. You can find supported values from the online PAM Administrator’s Guide. One special value is default, which means that all valuens that are not explicitly mentioned.

ActionN can take one of the following forms:

  • Ignore: If this action is used with the module stack, the module’s return status does not affect the return code the application gets.

  • Bad: indicates that the return code should be considered an indication of module failure. If this module is the first module in the stack to fail, its state value is used for the entire stack.

  • Die: Equivalent to BAD but may terminate the module stack, and PAM immediately returns it to the application.

  • Ok: This tells PAM that the system administrator thinks the return code should directly affect the return code for the entire module stack.

  • Done: Equal to OK but may terminate the module stack, and PAM immediately returns to the application.

  • N (an unsigned INTEGER) : equivalent to OK but may skip the next N modules in the stack.

  • Reset: This action clears all memory for the module stack state and restarts from the next stack module.

Each of the four keywords: required; requisite; sufficient; And Optional, in […] There is an equivalent expression for both syntactically, which allows you to write more complex rules, which are:

  • required: [success=ok new_authtok_reqd=ok ignore=ignore default=bad]
  • requisite: [success=ok new_authtok_reqd=ok ignore=ignore default=die]
  • sufficient: [success=done new_authtok_reqd=done default=ignore]
  • optional: [success=ok new_authtok_reqd=ok default=ignore]

Here is an example from a modern CentOS 7 system. Let’s consider these rules in the /etc/pam.d/postlogin PAM file:

# % PAM - 1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.session [success=1 default=ignore] pam_succeed_if.so service ! ~ gdm* service ! ~ su* quiet session [default=1] pam_lastlog.so nowtmp showfailed session optional pam_lastlog.so silent noupdate showfailedCopy the code

Here is another example configuration of the /etc/pam.d/ Smartcard-auth PAM file:

# % 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        [success=doneignore=ignore default=die] pam_pkcs11.so nodebug wait_for_card auth required pam_deny.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account required pam_permit.so  password required pam_pkcs11.so session optional pam_keyinit.so revoke session required pam_limits.so -session optional  pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so servicein crond quiet use_uid
session     required      pam_unix.so
Copy the code

For more information, see the Pam.d man page:

man pam.d 
Copy the code

Finally, a comprehensive description of the configuration file syntax and all PAM modules can be found in documentation for Linux-PAM.

conclusion

PAM is a powerful advanced API that allows programs that rely on authentication to provide user authentication to applications in Linux systems. It’s powerful, but also very challenging to understand and use.