Linux PAM Module Configuration

Posted on | Edited on | In

When I was working on non-root set up worker containers or pods, in order to grant the non-root user su password-less privilege, I got into PAM module in RHEL. Let’s spend time to understand it.

Pluggable authentication modules (PAMs) are a common framework for authentication and authorization.

There are many programs on your system that use PAM modules like su, passwd, ssh and login and other services. PAM main focus is to authenticate your users.

PAM or Pluggable Authentication Modules are the management layer that sits between Linux applications and the Linux native authentication system.

For full details, please refer: USING PLUGGABLE AUTHENTICATION MODULES (PAM) CHINESE VERSION

Each PAM-aware application or service has a file in the /etc/pam.d/ directory. Each file in this directory has the same name as the service to which it controls access. For example, the login program defines its service name as login and installs the /etc/pam.d/login PAM configuration file.

What I have done is add a non-root user, for example demo, to wheel group (usually wheel group is pre-existing), operate this as root user:

1
usermod -a -G wheel demo

Why wheel group? What is wheel stand for in computing? In computing, the term wheel refers to a user account with a wheel bit, a system setting that provides additional special system privileges that empower a user to execute restricted commands that ordinary user accounts cannot access.

Modern Unix systems generally use user groups as a security protocol to control access privileges. The wheel group is a special user group used on some Unix systems to control access to the su or sudo command, which allows a user to masquerade as another user (usually the super user).

By default it permits root access to the system if the applicant user is a member of the wheel group.

Check demo group information:

1
2
3
id demo

uid=1010(demo) gid=1010(demo) groups=1010(demo),10(wheel)

You can also go to /etc/group file to check group members of wheel:

1
wheel:x:10:demo

Then go to edit /etc/pam.d/su file to uncomment this directive:

1
2
# Uncomment the following line to implicitly trust users in the "wheel" group.
auth           sufficient      pam_wheel.so trust use_uid

What is pam_wheel.so? The pam_wheel PAM module is used to enforce the so-called wheel group. By default it permits root access(su - ) to the system if the applicant user is a member of the wheel group. If no group with this name exist, the module is using the group with the group-ID 0.

Now the user demo can su to other users (include root) without password. You can run command as another user:

1
su - <another> -c "<command>"

If you also want to have sudo password-less privilege for wheel group user, you need to edit /etc/sudoers file by visudo as root like this:

1
2
3
4
5
## Allows people in group wheel to run all commands
#%wheel       ALL=(ALL)       ALL

## Same thing without a password
%wheel        ALL=(ALL)       NOPASSWD: ALL

PAM file format

Each PAM configuration file, such as /etc/pam.d/su contains a group of directives that define the module (the authentication configuration area) and any controls or arguments with it.

The directives all have a simple syntax that identifies the module purpose (interface) and the configuration settings for the module.

1
module_interface	control_flag	module_name module_arguments
  • module_name — such as pam_wheel.so
  • auth — This module interface authenticates users. For example, it requests and verifies the validity of a password. Modules with this interface can also set credentials, such as group memberships.

All PAM modules generate a success or failure result when called. Control flags tell PAM what to do with the result. Modules can be listed (stacked) in a particular order, and the control flags determine how important the success or failure of a particular module is to the overall goal of authenticating the user to the service.

  • sufficient — The module result is ignored if it fails. However, if the result of a module flagged sufficient is successful and no previous modules flagged required have failed, then no other results are required and the user is authenticated to the service.

Let’s see an example:

1
2
3
4
5
6
[root@MyServer ~]# cat /etc/pam.d/setup

auth       sufficient	pam_rootok.so
auth       include	system-auth
account    required	pam_permit.so
session	   required	pam_permit.so

Here the modules are stacking, from up to bottom, verify each directive one by one,

  • auth sufficient pam_rootok.so — This line uses the pam_rootok.so module to check whether the current user is root, by verifying that their UID is 0. If this test succeeds, no other modules are consulted and the command is executed. If this test fails, the next module is consulted.

  • auth include system-auth — This line includes the content of the /etc/pam.d/system-auth module and processes this content for authentication.

PAM uses arguments to pass information to a pluggable module during authentication for some modules.

  • trust: The pam_wheel module will return PAM_SUCCESS instead of PAM_IGNORE if the user is a member of the wheel group

  • use_uid: The check for wheel membership will be done against the current uid instead of the original one

0%