PAM!!Intro to Linux Pluggable Authentication Modules

Every time you log into a Linux system, you’re using the Pluggable Authentication Modules (PAM) behind the scenes. PAM simplifies Linux authentication, and makes it possible for Linux systems to easily switch from local file authentication to directory based authentication in just a few steps. If you haven’t thought about PAM and the role it plays on the system, let’s take a look at what it is and what it does.

Actually, PAM is about more than logging into the system itself. Applications can use the PAM libraries to share authentication — so users can use a single username and password for many applications. The rationale behind PAM is to separate authentication from granting privileges. It should be up to the application how to handle granting an authenticated user privileges, but authentication can be handled separately.

A simple way of looking at this. Imagine going to an all-ages show at a local club. At the door, the bouncer checks ID and tickets. If you’ve got a valid ticket and ID that shows you’re over 21, you get a green wristband. If you’ve got a valid ticket and an ID that shows you’re under 21, you get a red wristband. Once in the club, it’s up to the bartender to grant privileges to buy alcohol (or not), and the club staff to grant seating privileges or direct you to the floor for general admission.

There’s no beer or music involved, but PAM is meant to work in a similar fashion.

Understanding PAM

Out of the box, most Linux installations are configured to use file-based authentication. Note that other systems also have PAM implementations, but for the purpose of this article we’ll stick to Linux.

For file-based authentication on modern Linux systems, users log in and their username and password combination is compared against /etc/shadow. Traditionally this was held in/etc/passwd, but the problem was that many programs needed to be able to read/etc/passwd. This meant that, in effect, anyone with local access could attempt to crack passwords — and without going into the details here, it was not beyond the realm of possibility that they’d be successful. This is doubly true when users are allowed to pick their own passwords and with no form of password policy enforcement.

So now user passwords are held in /etc/shadow, while things like the user shell and group are stored in /etc/passwd.

For single-user systems or small shops, this sort of file-based authentication is manageable. If you’re working with a small number of users on a handful of machines, it’s not difficult at all to deal with user account creation and user management manually using the standard tools provided by the distros.

But imagine if you have a 50-server environment which requires user synchronization across all systems. Suddenly you start dealing with issues of scale. You want to be able to use a directory service like OpenLDAP, or Microsoft’s Active Directory. But how? By switching away from the standard *nix password file method, and switching to an authentication module that supports the method you want to use.

Writing a module for PAM is well beyond the scope of this article. You shouldn’t need to anyway — plenty of modules exist already for any solution you’d want to use.

Take a look under /etc on a Linux system. On most popular distributions like Ubuntu Linux or Red Hat Enterprise you’ll find a directory, pam.d that has several files. Sometimes the configuration is held in /etc/pam.conf, but on many systems it’s broken out into several files by application. Remember, PAM is about more than just the initial login — it can also be used by other system applications that require authentication.

Let’s stick with login for now. Look at /etc/pam.d/login. This is the file used for the shadow login service. Here you’ll see quite a few directives for configuring the types of logins allowed, the type of authentication to be used, how long to delay another login if one fails, and much more. Here’s an example:

auth optional pam_faildelay.so delay=3000000

Basically, you’re calling the pam_faildelay module on authentication. If the user fails the attempt, it sets a delay so that any attacker trying to brute-force the way into a system will spend more time trying user/password combinations. Other PAM modules exist such aspam_succeed_if which will only allow an authentication to occur when an additional requirement such as being member of a certain group or your UID is within a certain range.

What if you want to change the type of authentication the system is using? Then you want to look at /etc/pam.d/common-auth, which defines the type of authentication being used to log into the system. It’s what points the system to /etc/shadow in the first place.

Here you can configure the system to use OpenLDAP, or other directory services. But there’s one more piece that needs to be changed, /etc/nsswitch.conf. This file tells the system what name services and directories to use for authentication, as well as where to look for protocol information (usually /etc/protocols, logically enough) and more. It’s sort of like your system’s Little Black Book, or the index to a Little Black Book.

Again, this goes back to the days when systems had One True Login and One True DNS, rather than a bunch of options. Now you can configure things so that the system uses OpenLDAP or Microsoft Active Directory (via Likewise, or Centrify) for authentication rather than static files. Another benefit of PAM is that it logs both successful and failures in common places, which allows you to use products specializing in reporting functionality to track whether logins are succeeding or failing.

As you can see, there’s a lot going on behind the scenes with PAM. You may have thought that Linux authentication was a simple affair, but there’s a lot of hidden (we hope) complexity and flexibility running the system when you provide your username and password. You’ll also find that Linux is very flexible, and can accommodate just about any authentication mechanism you’d like to use