PAM

Questions were asked in the Cypherpunks mailing list about PAM. This is acheived using Pluggable Authentication Modules. As the name suggests, they're kernel modules. They can be added to an existing Linux installation, although you'd find they're often included by default.

Background

The old way of doing this was that programs that required user or elevated privileges would request a username/password and compare that with entries in /etc/passwd. PAM essentially swapped this method of authentication with the use of shared security modules, so each could authenticate independently.

There are several categories of operation that could be performed by a module:

Authentication
Account
Credential
Session management
Password

There are also implementations for variants of BSD, and Java-based implementations also.

If we look at the list returned by the apt package manager, we can see the list of installed and available modules for Ubuntu/Debian. We find there are modules for pretty much everything that might require authentication, such as SSH and FTP.

PAM Configuration

Configuration files exist in /etc/pam.d, a central file being in /etc/pam.d/other. You might end up with several configuration files, each file for a PAM operation category, e.g.

/etc/pam.d/system-account ( account required pam_unix.so )
/etc/pam.d/system-auth ( auth required pam_unix.so )
/etc/pam.d/system-session (session required pam_unix.so )

Meanwhile, /etc/pam.d/other might contain the restrictive rules. e.g. auth required pam_warn.so or: password required pam_deny.so

Configuration File Entries

Each line in a PAM configuration is in the following format: [Type] [Control Flag] [Module Name] Type = The authentication action, such as authentication or password change, or session control.
Control Flag = Is authentication required, denied or allowed?
Module = The PAM module implementing the action. This could allow the action, return an authentication fail message or log a failed attempt.

Supported types are:

account: Manages account policies, such as whether the user is allowed to authenticate, account expiry, etc.
auth: Handles authentication, which isn't necessarily user/password combination. Could be 2FA, biometric or token.
password: Handles changes in authentication details, usually password changes.
session: Typically handles the actions performed after the user has authenticated and signed out.

Supported control flags:

requisite: Authentication with the named module is required to perform whichever action.
required: Same as above, but another module could be selected if authentication fails.
sufficient: User is authenticated if successful with the specific module, even if previous attempts had failed.
optional: Module is not strictly necessary for action to be performed.

Multiple actions can also be chained for an authentication attempt. e.g.


				auth  required  pam_warn.so

				auth  required  pam_deny.so

Module Structure and Content

Taking an example from Roy Keane's blog, we can quickly get an understanding of the module structure. The interfaces provided by the module are listed in the source header. You'll recognise these interface names:


				#define PAM_SM_ACCOUNT

				#define PAM_SM_AUTH

				#define PAM_SM_PASSWORD

				#define PAM_SM_SESSION

And there are also PAM module header files:


				#include 

				#include

Now let's look at one of the functions within the module, picking just the first one in the example source:


				int pam_sm_open_session(pam_handle_t *pamh, int flags, int argc, const char **argv) 

				{

					return(PAM_IGNORE);

				}

This function, pam_sm_open_session() takes the following parameters, which seem common to PAM module functions:

pam_handle_t
pamh
flags
argc
argv

These seem to correspond to the fields of a typical configuration entry, with flags referring to the required/requisit/sufficient/optional field, argc referring to the module name, and argv referring to the module option. I've looked up argc and argv, and this does seem the case.

As we can see, the function does very little but return PAM_IGNORE to the calling function.

References

KEENE, R. 2012. Writing Your First PAM Module. Roy Keene's Wiki. [BLOG]. http://www.rkeene.org/projects/info/wiki/222. (26th June 2017).

LINUX DOCUMENTATION PROJECT. 2017. 3. PAM (Pluggable Authentication Modules). The Linux Documentation Project: User Authentication HOWTO. [WWW]. http://tldp.org/HOWTO/User-Authentication-HOWTO/x115.html. (26th June 2017).

LINUX FROM SCRATCH. 2017. Linux-PAM-1.3.0. Beyond Linux from Scratch. [WWW]. http://www.linuxfromscratch.org/blfs/view/svn/postlfs/linux-pam.html. (26th June 2017).

MORGAN, A. G. 2000. Pluggable Authentication Modules. PAM Working Group. The Linux Kernel Archives. [TXT]. https://www.kernel.org/pub/linux/libs/pam/pre/doc/draft-morgan-pam-07.txt. (26th June 2017).

SRIVASTAVA, V. 2009. Understanding and configuring PAM. IBM developerWorks. [WWW]. https://www.ibm.com/developerworks/library/l-pam/. (26th June 2017).

TUXRADAR. 2009. How PAM works. TuxRadar. [WWW]. http://www.tuxradar.com/content/how-pam-works. (26th June 2017).

Pluggable Authentication Modules (PAM)

Background

PAM Configuration

Configuration File Entries

Module Structure and Content

References