Security 101: Account Security - PAM!

It is generally easier to attack a system when you already have access to an account. And the more privileges the account has, the bigger the damage you can do.

A privilege escalation attack is a threat! Privilege escalation is when you get elevated access to resources that are usually protected and/or beyond your access. Software bugs or insecure configurations can be exploited and used for privilege escalation!

The first line of defense is to keep malicious users (and users who have no reason to access the system) out of the system.

The next way to secure/limit the accounts so that they can access only what each user is intended to.

Image source: Linux Explore

Previous parts:

1. Introduction
2. General Principles and Guidelines
3. Physical Security: Intro
4. Physical Security: Single User Mode
5. Physical Security: Securing your Bootloader
6. Physical Security: Disk Encryption I
7. Physical Security: Disk Encryption II
8. Physical Security: Control+Alt+Delete & Wrapping it up

PAM - Pluggable Authentication Modules

In the past, each piece of software had to provide its own authentication method. The login software would look at /etc/password & /etc/shadow to verify username and password combos.

Pam is a centralised authentication mechanism used on most linux distros. PAM takes the work off of each software, and verifies the details itself. The upside of this is that if a new method becomes available (for example fingerprint sensors), it can easily be added on the system and the software doesn't have to be rewritten to support fingerprint scanning!

Config files of PAM are in /etc/pam.d/. Inside, each file is used by a program to configure authentication.

Modules

PAM uses 4 types of module interfaces. These interfaces correspons to various authorisation aspects:

Auth module is the most commonly used to authorise access to systems/software
Account module is being used to verify if access is permitted to the target system/software. It checks if the account isn't logged and its password hasn't expired. If for example you restricted an account to be able to be used only business hours, then, this module is used to verify that the account can or can't be used at the moment.
Password module is used to change passwords.
Session module is used to manage sessions. It can be used to perform various actions, such as mounting the home dir of a user.

A module can use 1 or more (or even all) of the above interfaces.

Control Flags

All modules generate a success or failure result when called. Using control flags, you can tell PAM what to do with each result. Modules can be listed and stacked in a particular order, and the control flags determine how important the success/failure result of a each module is to allow the user gain access to the system or service.

Required - this flag tells PAM that to continue, the result HAS TO BE success. If this fails, the user won't get notified until the whole process is finished.
Requisite - The same as required, but in case of a failure it will stop there (no other modules will be invoked) and notify the user.
Sufficient - Authenticate the user if no required modules have failed. If a required module has failed, this module is ignored and the user won't get authenticated.
Optional - Optional modules will get used ONLY if there are no other modules are referencing the interface.
Include - This is pretty much self explanatory. Includes the configuration from another file.

There are also various more complex control flags in the sense of "-attribute=value". You can find a complete list on the man page of pam.d

Sample PAM config 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_pwquality.so retry=3
password  required  pam_unix.so shadow nullok use_authtok
session   required  pam_unix.so

[Source: CentOS]

The first line is a comment, as it starts with a hashtag (#).

The second line is a directive: use auth module, telling PAM that is required, and pam_securetty.so is the authentication module used.

You can see that we also have 2 more auth required lines. This is called a "stack". If those 3 are successes the user will be authenticated.

Let's see what each auth module does:

securetty.so: This module makes sure that if the user is trying to log in as root, the TTY on which the user is logging in is listed in the /etc/securetty file, if that file exists. If the TTY is not listed, any attempt will result as failure.
pam_unix.so: This module prompts the user for a password and then checks the supplied password using the information stored in /etc/passwd and /etc/shadow. The nullok on the right instruct the module to accept null passwords.
pam_nologin.so: This is the final authentication step. It checks if the file /etc/nologin exists. If it does exist and the user is not root, authentication fails. If at any point you want to disallow any users from logging in, you can just create the file and non-root users will not be able to access the system. Everything you type as file contents, will be shown to a user that tries to login (useful to explain why they can't login, and for how long this will go on)

The fifth line is an account module, that will verify that the user's password hasn't expired and the account is not disabled.

If the password is expired, the sixth line comes into play. pwquality is a password module, that asks the user for a new password, and checks if it is a very simple password, or a dictionary word. The retry=3 on the right, instructs the module to give the user a total of 3 tries to create a new and acceptable password, otherwise returns an error.

The seventh line, tells PAM to use the interface of pam_unix.so, with 3 arguments: shadow (use shadow passwords), nullok (allow the user to change from a blank password. if this isn't used, blank password means a locked account), and use_authtok (uses the previously gathered password, in this example from the line where it asked the user to change the password).

The eighth and final line uses the session interface of pam_unix.so module. That module logs the time a user logs in and out of a system to a log file.

You can get more help about this by reading the documentation for each module. For example, you can read man pam_unix for the pam_unix.so module, what arguments it accepts, and how else it can be used with the various interfaces.

In the "Account Security" we will be using PAM to implement various security measures. Next part is now available, click here to read it

Thank you for reading, leave your thoughts below and, of course, don't forget to upvote!

Also, I am running a witness server.

Please consider voting me, dimitrisp, for a witness if you find what I post & do helpful and add value to the network

You can read my witness declaration here

Sort Order:

Trending

[-]

nachon (49) · 7 years ago

seems helpful..
nice post yeah..!!

$0.00

the-tech-guy (49) · 7 years ago

Very nice post, thanks for taking the time! I would be grateful if you could give an example of how to use these modules in a concrete way, like e.g. in a python script or a c++ program.

dimitrisp (68) · 7 years ago

In python you could use something like this:

import pam

if pam.authenticate('username','password'):
    print 'authentication correct'
else:
    print 'authentication incorrect'

You'll need the python-pam module. I have no Python experience, got the code from Stack Overflow, so it may/may not work.

You can also see this code sample in Stack Overflow for using PAM in C++ to get an idea and implement it in your own code.

I plan to make some examples in the series though.

$0.06

1 vote

Thank you. I'm looking forward to it.