Pluggable Authentication Modules (PAM)

Pluggable Authentication Modules for Linux (Linux-PAM) is a great way to fit your Linux server with authentication-related services. However, we found their use pretty difficult, due to some aspects of PAM not being as obvious as the tutorial and howto-writers apparently expect. Thus, we here try to explain ourselves (and you, dear reader) how PAM works.

PAM introduction

What is PAM

Most Linux applications require authentication of some type or another. For authentication, multiple mechanisms are available, ranging from the standard Linux password through certificates all the way to smartcard readers, fingerprint readers and what have you not. To make use of one (or more) of these mechanisms, there are two main choices: either program the code required to interface with your authentication mechanism of choice, or make use of some framework that can take care of the interfacing with the authentication mechanism for you.

It will be clear that programming authentication mechanism support is not usually a smart move; for any new authentication mechanism, as well as for any change in existing ones, you need to reprogram, recompile et cetera. Connecting to a framework on the other hand is a one-time effort, requiring only extra effort if and when the framework itself changes. And here we encounter PAM, because PAM is just such a framework.

Free after the PAM admin guide: Linux-PAM is a suite of shared libraries. Using these libraries, the local system administrator can specify how PAM-aware applications authenticate users. In other words, if an application or service is PAM-aware, then it is possible to switch between the authentication mechanism(s) it uses without (rewriting and) recompiling it. Indeed, one may entirely upgrade or reconfigure the local authentication system without touching the applications themselves. Furthermore, the administrative effort associated with authentication managemnet is reduced, since all configuration using the framework is the same for any application using it. In other words: admins have to learn only once to operate the framework, and can then deploy and configure any application using it.

Historically, an application that required a given user to be authenticated had to be compiled to use a specific authentication mechanism. For example, in the case of traditional UN*X systems, the identity of the user is verified by the user entering a correct password. This password, after being prefixed by a two character "salt", is encrypted (with crypt(3)). The user is then authenticated if this encrypted password is identical to the second field of the user's entry in the system password database (the /etc/passwd file). On such systems, most if not all forms of privileges are granted based on this single authentication scheme. Privilege comes in the form of a personal user-identifier (UID) and membership of various groups. Services and applications are available based on the personal and group identity of the user. Traditionally, group membership has been assigned based on entries in the /etc/group file.

It is the purpose of the Linux-PAM project to separate the development of privilege granting software from the development of secure and appropriate authentication schemes. This is accomplished by providing a library of functions that an application may use to request that a user be authenticated. This PAM library is configured locally with a system file, /etc/pam.conf (or a series of configuration files located in /etc/pam.d/) to authenticate a user request via the locally available authentication modules. The modules themselves will usually be located in the directory /lib/security or /lib64/security and take the form of dynamically loadable object files

PAM Principles

Invoking PAM

As you might expect from the previous texts, you can only use PAM if your application, service, daemon or program is "PAM-aware". This means, that it is coded and compiled to use PAM. Fortunately, in this day and age most applications, daemons et cetera are. However, this presents us with a true problem: that of choice. When your application is PAM-aware, it means that your application can deletate just about any imaginable authentication-task to PAM - which YOU, the system administrator, must achieve by invoking PAM in just the right way. To this end, you must create a PAM configuration file, and fill it with just the right information as to have PAM perform all tasks that you want - and none other.