Introduction
Linux PAM (Pluggable Authentication Modules) is a framework that provides a flexible and modular approach to authentication, authorization, and other security-related tasks in Linux-based systems
With PAM, authentication and authorization tasks can be delegated to various modules, each of which is responsible for a specific aspect of the process, such as password validation, smart card authentication, biometric authentication, and more
💡 The concept of PAM library is similar to the DLL library in Windows
How does it work?
- User attempts to log in or perform an action requiring authentication
- System checks if the service uses PAM
- PAM invokes the appropriate PAM stack
- Each module in the stack performs a specific task
- If all modules succeed, access is granted
- User is logged in or action is performed
PAM Library paths used
- /etc/pam.d => The config files for programs using the PAM library are present under this path
- /usr/lib64/security => Authentication modules provided by PAM library
- /etc/security => This contains config files required to execute PAM modules
PAM Types
- Account: Determines if the user is allowed access based on account properties
- Authentication: Verifies the user's identity with a credential, such as a password
- Password: Changes the user's password and enforces password policies
- Session: Sets up and tears down a user's session and performs related tasks
PAM Controls
- Required: If the module fails, the authentication process is immediately aborted
- Requisite: If the module fails, the authentication process is immediately aborted, but a failure is not logged
- Sufficient: If the module succeeds, the authentication process is immediately considered successful and no further modules are executed
💡 We also have:
Module-paths: PAM modules are loadable libraries, and the module-paths specify the location of these libraries in the system.
Module-arguments: PAM modules can take arguments that are specified in the PAM configuration file. These arguments are used to customize the behavior of the module or provide additional information to the module. The syntax for specifying module arguments is module-type control-flag module-path [module-arguments].
Hands on using rootok.so
We can do some simple tests using the /etc/pam.d/su
config file
# Adding a user with password
useradd s1
passwd s1
# Using the 'su' command to shift to s1 user
su s1
This won't require any authentication as we are the 'root' user
But what if we change a setting here?
vi /etc/pam.d/su
#%PAM-1.0
#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
auth substack system-auth
auth include postlogin
account sufficient pam_succeed_if.so uid = 0 use_uid quiet
account include system-auth
password include system-auth
session include system-auth
session include postlogin
session optional pam_xauth.so
In this file, we can comment out the second line and then test again
su s1
password:
This now requires a password as it ignores the 'auth sufficient' line for the root user
💡 We can test using required
or requisite
instead of sufficient
in the second line as well
-> required
will let the root user shift users using password but won't let normal users to shift even when the password is right
-> requisite
will let the user shift users using password but won't let normal users to shift at all, not letting the normal user to write the password at all
Next, we will look at line 3 and 4
Hands on using wheel
3 auth sufficient pam_wheel.so trust use_uid
4 auth required pam_wheel.so use_uid
Commenting out the second line and the 4th line
the pam_wheel.so trust use_uid
line allows users in the "wheel" group to execute privileged commands without a password prompt, and determines group membership based on the user's UID
the pam_wheel.so use_uid
line configures PAM to use UID-based group membership to determine if a user is a member of the "wheel" group and is allowed to execute privileged commands without a password prompt
We can check the wheel group
cat /etc/group | grep wheel
wheel:x:10:
Adding a user into this group
usermod -G wheel user1
# Confirming
cat /etc/group | grep wheel
wheel:x:10:itbank
Now if we shift to the user1, it will ask for the password and for the user1, it won't need any authentication for shifting to the root user which isn't the optimal situation.
Uncomment the second line and erase the 'trust' from the 3rd line
2 auth sufficient pam_rootok.so
3 auth sufficient pam_wheel.so use_uid
4 #auth required pam_wheel.so use_uid
Now the root user can shift to user1 without any password while the user1 has to use a password to shift to root user
So now what if we want the following
-> root > user1 (no password)
-> user1 > root (needs password)
-> user1 > user2 (no password)
For the config file /etc/pam.d/su
2 auth sufficient pam_rootok.so
3 auth required pam_wheel.so trust use_uid
4 auth sufficient pam_succeed_if.so uid >= 1000 quiet
Here the 4th line allows the PAM stack to silently return a success value if the user's UID is greater than or equal to 1000
The above configuration will allow the user1 to shift to user2 but if we try to shift from user2 to user1, it won't let us even using the password when prompted
👉 Reverse changes inside
/etc/pam.d/su
/etc/pam.d/system-auth
To fix this we do some edits in the following config file,
vi /etc/pam.d/system-auth
#%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_faildelay.so delay=2000000
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
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 requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password required pam_deny.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 service in crond quiet use_uid
session required pam_unix.so
We need to change some lines here,
auth required pam_env.so
auth required pam_faildelay.so delay=2000000
auth required pam_unix.so nullok try_first_pass
auth sufficient pam_succeed_if.so user != root quiet_success
auth sufficient pam_succeed_if.so user = user1 use_uid quiet_success
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth required pam_deny.so
Now,
- root user can shift to user1 and all other users without password.
- user1 can shift to other users with their passwords
- other users can shift to user1 with user1 password
- user1 has the only access to root user using the root user password
- other users cannot shift to root user
So we can actually implement this for remote access,
SSH -> PermitRootLogin NO
PAM -> The above configuration
This will make,
SSH => user1 login -> root user (to work as a root user)
✨ This will tighten the security more than normal SSH into the server as the root user
Top comments (0)