Michael W. Lucas - PAM Mastery

As always, I need to thank the technical reviewers who offered feedback on earlier drafts of this book: Bryan Irvine, Kurt Mosiejczuk, Mike OConnor, and Carsten Strotmann. Special thanks go to Dag-Erling Smrgravthe one-man army responsible for OpenPAMwho took time out of his busy schedule to educate me on some PAM fundamentals.

I also need to thank my horde of Twitter followers, who run many more operating systems than I believed were still in use, and cheerfully offered their particularly horrible PAM configurations for my edification.

All testing and research was done on servers from the generous folks at iX Systems, who have offered their support for my work for the last decade or so. The least I can do is thank them too.

Finally Id like to thank the world, for letting me pretend that rsh(1), pam_rhosts, and their surrounding ecosystem do not exist.

For Liz.

Authentication on Unix-like systems is perhaps the closest thing sysadmins have to black magic.

Every sysadmin has heard of Pluggable Authentication Modules, or PAM. We all know that the files in /etc/pam.d/ dictate how most software authenticates. If you want to use public key authentication, or authenticate with physical tokens, or rely only on passwords, you have to muck around in those files. Usually, sysadmins blindly follow the instructions and hope nothing terrible happens.

PAM policies are not exactly like anything else in systems administration. A set of PAM statements isnt processed like a set of packet filter rules or a shared library path, except when it is. Plus, PAM uses strange words like requisite, and the word sufficient apparently means anything but enough.

And when you break PAM, you break a whole service. Most services are hard enough to get running in the first place, so breaking them is discouraged. Hopefully its not the service that lets you log in to the machine.

PAM doesnt have to be black magic, however. Enabling Google Authenticator doesnt absolutely require sacrificing a black cockerel on the thirteenth full moon of the year with a knife freshly forged from matrilineally inherited silver. All you need are your sysadmin skills and this book.

PAM Mastery is written for systems administrators of moderate experience. You need to understand managing shared libraries, installing and removing software, and troubleshooting your preferred platforms.

Not all platforms have packages for all of the modules discussed. Using these modules requires building them from source code. While Ill give basic instructions on compiling modules, those instructions assume that youve compiled software before and understand how your platforms compiler behaves. On CentOS, youll need the Development Tools package group and the pam-devel package. On Debian youll need the build-essentials and libpam0g-dev packages. The FreeBSD ports system contains all of the modules this book discusses.

This book focuses on cross-platform solutions, especially for educational purposes. Perhaps your Unix-like system has a PAM module for exactly a specific task. Ill occasionally mention such modules as we go, but pay most attention to modules used by multiple operating systems.

Youll also need systems to test on. The nice thing about experimenting with PAM is that system requirements are minimal. Virtual machines are perfectly suitable for testing PAM. If youre trying something like using pam_exec to spawn a Perl process to manage authentication, youll want to perform load testing before deploying in production.

What will you get out of all of this? This book wont teach you the in-depth details of PAM on your preferred platform. It will teach you how to think about PAM, how the policies and modules work, and how to explore and master your preferred operating systems PAM implementation. Youll also carry the expertise gained here to any other PAM-using operating system.

Various security and computing bodies have redefined authentication to best suit their own needs. If you dig into security theory, youll stumble across the term Authentication, Authorization, and Accounting (AAA). Management Information Systems documents might focus on resource control, while sysadmins only care about matching the username and the password.

For purposes of PAM, authentication means validating a users credentials and establishing service for people who provide those credentials. The security experts who use the AAA terminology will tell you that PAM pulls all those roles together. Which it does. PAM also lets you configure different modules and services for the various components of AAA, however.

PAM not only verifies authentication credentials. It can arrange home directories, log access, enable services, and more. PAM integrates system services with authentication.

If youre accustomed to the term Identification, Authentication, and Authorization (IAA), you should know that PAM does not handle identification. Systems that rely on PAM normally use Name Service Switch (NSS) to manage identification. NSS also originated with Solaris, and predates PAM by a few years. The lack of integration between NSS and PAM has caused a continuous migraine for Unix-like systems ever since.

The phrase two-factor authentication gets batted around quite a bit. You can use PAM to implement two-factor authentication or, indeed, multi-factor authentication. The obvious question becomes: what is an authentication factor?

Authentication is based on one of three user characteristics: something they have, something they know, or something they are. Something they have refers to a physical token, such as a hardware security token or a cell phone tied to a specific phone number. These physical items are easily lost or broken. Something they know is a secret, such as a passwordand we all know that passwords get written on sticky notes and attached to the monitor. Something they are including biometric factors such as a fingerprint, an iris scan, or a gene scanmight seem best. But biometric data can be stolen. Changing your iris scan pattern in response to that theft is beyond the scope of this book.

Multi-factor authentication requires two or more of these factors. Maybe you need a security token and a particular cellphone and a password and a fingerprint. An intruder can capture any one of these without too much trouble, but grabbing every necessary piece is exponentially more difficult.

The second half of this book includes several PAM modules that add an authentication factor, such as Google Authenticator (Chapter 9) or used for specific purposes, like the pam_passwdqc password quality checker (Chapter 11).

If Pluggable Authentication Modules are such a pain, why use them?

Because most of the alternatives are worse.

In the early days of computing, every program needed separate configuration to support any desired authentication methods. If you wanted a new workstation to match the standards demanded by your enterprise network, you needed to adjust every program on that workstation. Some of those programs needed configuration file changes, while others demanded full-out recompiling. No software or operating system supported all authentication methods. And if you wanted to do something even a little different good luck!