How PAM(Pluggable Autthentication Module) Works

PAM (Pluggable Authentication Modules) is one of those dark corners of Linux where most users don't venture - in fact, I'd be willing to bet that the majority of Linux users don't even know what it is. And yet, PAM is at the heart of every single thing in Linux to do with authentication.

Take our guided tour of PAM, join our science lab and perform our experiments (no bunsen burner necessary!) and see how PAM gives you fine-grain control over your security policy.

Getting to know PAM

PAM is a framework that assists applications in performing what I'll call "authentication-related activities". The core pieces of PAM are a library (libpam) and a collection of PAM modules, which are dynamically linked libraries (.so) files in the folder /lib/security.

Each module performs one specific task, and a "PAM-aware" application typically uses a stack of several modules to get the job done. Figure 1 below shows the overall architecture.

Figure 1: the PAM architecture and how its different parts are related.

PAM recognises four kinds of authentication-related activity, named as follows:

• auth is the most obvious activity - the actual business of proving who you are by supplying valid credentials. The traditional way of doing this is with a user-name and password, but other methods are possible such as the possession of a physical token or even biometric methods such as fingerprints or retinal scans.
• account is the business of deciding if, (now we know who you are,) we're going to let you log in. For example, a PAM module that implemented time-of-day login restrictions would fall into the account category.
• session allocates the resources that a user might need during a login session, for example, mounting the user's home directory, setting resource usage limits, printing a message of the day, etc.
• password updates a user's credentials (usually their password).

For brevity I'll refer to these four activities as "PAM activities".

Which programs use PAM?

Well, any program that needs to authenticate users, control logins, allocate resources to users, or update login credentials can make its life easier by using PAM. Obvious candidates are programs like:

• login the program that lets you log in on character terminals.
• gdm lets you log in to a graphical desktop.
• su lets you start a shell with a new identity.
• passwd lets you choose a new password.

The benefit of PAM is that it separates the details of how "authentication-related activities" are to be performed from the applications that need to carry out these activities. This makes it relatively easy to change your security policy, or to add new authentication mechanisms, simply by reconfiguring PAM. In the era before PAM, changes like that would have required source-code changes to the applications themselves.

Is a program PAM-aware?

How can we tell if a particular program uses PAM? Well, one way is to look at the config files in /etc/pam.d. In theory, that should tell us which programs are using PAM. A more scientific way is to see if the program is linked against the PAM library. You can do this with a command such as:

$ ldd /bin/login | grep libpam
        libpam.so.0 => /lib/libpam.so.0 (0xb7f47000)
        libpam_misc.so.0 => /lib/libpam_misc.so.0 (0xb7f43000)

If you see similar output, the program uses PAM. If there is no output, it doesn't.

The stack of modules that each PAM-aware application uses to perform each of our four authentication-related activities is specified in a PAM configuration file in the folder /etc/pam.d. The file is named after the application, so for example /etc/pam.d/sshd is the configuration file for the program sshd.

Figure 2: PAM config file syntax.

Figure 2, above, shows one line from such a file; this particular line adds the module pam_unix.so to the auth stack. An application can assemble all four stacks (one for each PAM activity) if it needs to, but many applications only need one or two of them.

Now, the basic idea goes like this: when a PAM-aware application wants to perform a PAM activity, it asks the PAM library to do the job. The PAM library then calls each of the modules in that activity's stack, in turn. Each of the modules "does its thing", and returns a pass/fail indication to the library.

The PAM library combines these pass/fail results into a pass/fail result for the stack as a whole. This result is then returned to the application. The way in which the pass/fail results of the individual modules are combined is determined by the control flag associated with the module. This flag is the second field of the entries in the pam config file. The possible settings are:

• requisite: If this module fails, PAM immediately returns a failure result to the application; no further modules in the stack are called.
• required: If this module fails, PAM returns a failure result to the application but it will continue to call the next module in the stack. (If you find you have trouble remembering the distinction between requisite and required, then join the club! So do we...)
• sufficient: If this module succeeds, PAM returns a 'pass' result to the application and no further modules in the stack are called. (This assumes, of course, that a required module hasn't failed higher up the stack.
• optional: The pass/fail result of this module is ignored, which generally means that the module is being called to perform some operation, rather than participating in the pass/fail decision for the stack. For example, the pam_keyinit module is used as an 'optional' module by sshd to create a new 'session keyring' for the new login.

(Recent versions of PAM support a more fine-grained result from a module than just pass/fail, and a more complex configuration syntax to define how these results are combined to provide an overall result for the stack. See the manual page for pam.conf - if you have one - for the details. However, the basic pass/fail behaviour is enough to be going on with!)

You will also see the include keyword used as a control flag. This is a little different from the others. It tells PAM to include some other pre-defined module stack (in programming terms you'd think of it as calling a subroutine). This is used to 'factor out' common PAM behaviours (ie common module stacks) into a separate file.

For example, in RHEL5 you'll find that many PAM config files include the stack defined in the file system-auth. Or, in Ubuntu, you'll find four files: common-auth, common-account, common-session and common-passwd that serve a similar purpose. Red Hat also uses a sort of 'meta-module' called pam_stack, that runs a stack of modules specified in a separate file, and serves much the same purpose.

Now that you've got some idea how PAM hangs together, you might like to take a look at the big table at the end of this tutorial, which lists some commonly-used PAM modules. Note that not all of these modules may be included in your particular distribution. On the other hand, you'll come across modules that aren't in this table.

Linux being an open system and all that, folks have written PAM modules to do all kinds of things. Take a look at http://www.kernel.org/pub/linux/libs/pam/modules.html for some links.

We're about to go over some experiments in changing the PAM configuration. None of them is especially exciting by itself, but my hope is that they will give you enough confidence and understanding of how PAM works to start making experiments of your own.

Allow any user to su to root without a password.

What you need to do: Edit the file /etc/pam.d/su and comment out any lines relating to the auth stack, replacing them with the single line:

auth    sufficient    pam_permit.so

How to test it: Log in as a normal user and verify that you can now use su to become root without supplying a password. This may seems like a very insecure arrangement, but it's less dangerous than having folks just log in as root in the first place. You can log in as a normal user then run a command like

$ su -c "date 09201155"

to adjust the system clock, for instance (an activity that requires you to be root).

Prevent all users from using su

What you need to do: Edit the file /etc/pam.d/su so that the only line relating to the auth stack reads:

auth     requisite    pam_deny.so

How to test it: Log in as a normal user and verify that any attempt to become root now fails instantly. You're not even asked for a password. Of course you could also disable su by turning off execute permission on the program itself. Although disabling su might feel like you're making things more secure, you're actually forcing a system administrator to log in directly as root, rather than just transitioning briefly to root when he needs root privilege.

Allow only members of the wheel group to use su

What you need to do: First you'll need to have at least one user account that is a member of the wheel group. For example, to add user chris to the wheel group, enter this command as root:

# usermod -G wheel chris

Now you should edit the file /etc/pam.d/su so that the auth stack looks like this:

auth    sufficient    pam_rootok.so
auth    required      pam_wheel use_uid
auth    include       system-auth

How to test it: Log in as chris (or whichever user you added to the wheel group) and try to use su. You'll be asked for the root password and then you should get a root shell. Now try to use su whilst logged in as a user who is not a member of the wheel group. You'll still get asked for the root password, but your attempt to become root will fail. You might like to try changing the control flag for the pam_wheel module to requisite - that is, change the line in /etc/pam.d/su to:

auth    requisite      pam_wheel use_uid

What difference in behaviour would you expect to see? Test it to see if you're right. Do you begin to see how the configuration of PAM determines your security policy?

Disable direct root login

The idea here is to prevent users from logging in as root, so that they must log in as a normal user then use su to achieve root status. (Before doing this, ensure that you have at least one account that can use su to become root, or you will lock yourself out from the machine.) We need to handle two cases - logging in on virtual terminals, and logging in on the graphical desktop.

What you need to do: To disable root logins on virtual terminals, edit the file /etc/pam/d/login and add the entry

auth    required    pam_securetty.so

at the top of the auth stack. (It may already be there.) As we saw, this module will prevent root login on terminal devices that aren't listed in /etc/securetty. So now we can empty this file with these commands:

# cp /etc/securetty /etc/securetty.saved
# echo "" > /etc/securetty

(Note that having an empty /etc/securetty file is quite different from not having one at all. The former disables root logins on all terminals, the latter enables root logins on all terminals.) Next, to prevent root logins on the desktop, add the same line to the top of the auth stack in the file /etc/pam.d/gdm.

How to test it: Try logging in as root (supplying the correct password) both on a virtual terminal and on the graphical desktop. Both should fail. Verify that you can still log in as a non-root user. Notice that if you perform Experiment 3 in addition, you have substantially strengthened your system because to become root you must first log in as a member of the wheel group, then use su to become root. Knowledge of the root password, by itself, is not sufficient to gain root access.

Enforce strong passwords

In this experiment we'll use the pam_passwdqc module on the password stack to ensure that users choose strong passwords. (Note that this will only make any difference when users set or change their passwords; it won't winkle out weak passwords that are already set.)

What you need to do: Red Hat already uses the pam_cracklib module to check password strength in the common system-auth file. We simply need to replace the pam_cracklib line with a line that looks something like this:

password    requisite    pam_passwdqc.so  min=12,10,10,8,6 retry=3

Figure 3: pam_passwdqc parameters.

Figure 3 above attempts to illustrate the parameters to pam_passwdqc. The test of a password's strength is based on its length, but you can set different minimum lengths depending on the number of character classes in your password. There are four character classes: lower case, upper case, digits, and other characters. Upper case letters used as the first character and digits used as the last character of a password don't count.

How to test it: Try changing your password to various strings; in each case count the number of characters and the number of character classes in the string and predict if it should be an acceptable password. There are a few examples in the table below.

Password	Length	Character Classes	OK?
monpiastoria	12	1	Yes
LinuxFormat	11	2	Yes
beld*Grob	9	3	Yes
4Me+You	7	4	Yes
splodgerat	10	1	No
Four+five	9	2	No
gosH!!2	7	3	No
x4Z!	4	4	No

Prevent non-root users from shutting down the system

Many systems allow ordinary (non-root) users to shut down or reboot the system using commands like halt, shutdown and reboot. On a production machine this may not be a good idea. In this experiment, we'll change the PAM configuration of these commands so that only root can halt the machine.

What you need to do: Taking the PAM configuration of the halt command as an example, edit the file /etc/pam.d/halt. On my Red Hat system the auth stack for halt looks like this:

auth       sufficient   pam_rootok.so
auth       required     pam_console.so

Change the stack to look like this:

auth       sufficient   pam_rootok.so
auth       required     pam_deny.so

How to test it: Log on as a non-root user and try to halt the system with the command halt. You should no longer be allowed to do this. For a more complete solution you would need to make similar changes to the config files for shutdown and reboot.

Commonly used PAM modules

Module	Activities	Description
pam_unix	auth, session, password	Performs traditional Unix-style authentication against hashed passwords stored in /etc/shadow. You'll find it included in the pam config files of many applications, either directly or via an include directive.
pam_limits	session	Sets a limit on the system resources than can be used during a user session. By default the limits are taken from the file /etc/security/limits.conf; here you can set hard and soft limits for things such as the maximum number of process, the maximum file size, the maximum CPU time, and so on.
pam_rootok	auth	Succeeds if you're root and fails if you're not. It's as simple as that. It is usually used in combination with some other authentication module to establish a policy of "if you're root you can go ahead and do it; otherwise you need to authenticate." The stack for this policy might look like this: auth sufficient pam_rootok.so auth required pam_unix.so
pam_cracklib	password	Performs password strength checking, testing the password against a system dictionary and a set of rules for identifying poor choices. It's usually used on a password stack to verify password strength before handing the password on to the next module in the stack (typically pam_unix) to actually update the password.
pam_passwdqc	password	An alternative module for password strength checking; it also provides support for pass phrases and can provide randomly generated ones. Like pam_cracklib it would typically be used on a password stack to verify password strength before updating it. For a detailed example, see Experiment 5.
pam_permit	auth, account, session, password	This module just says "yes" to everything. It always returns success.
pam_deny	auth, account, session, password	This module just says "no" to everything. It always returns failure. Typically it would only be used right at the bottom of a PAM stack to guarantee failure.
pam_warn	auth, account, session, password	Simply logs a message (including the service name, the terminal, the user name and the remote host) to the message logging service syslogd. It might be used, for example, near the bottom of a PAM stack to log a failed authentication attempt, just prior to denying it with pam_deny.
pam_motd	session	Displays a message of the day file (by default, the file /etc/motd), typically after a successful login.
pam_securetty	aurg	No, this is not a misspelling of "security". The pam_securetty module restricts root logins to "secure terminals"; that is, to terminals that are listed in the file /etc/securetty. (Remember, tty is Linux-speak for "terminal device"). The module has no effect for non-root logins. This kind of access control made more sense back in the days when Unix ran on multi-user minicomputers with twenty terminals plugged into RS232 ports; the securetty file could be used to restrict root logins to the terminal that was locked in the system administrator's office. However it can still be useful to disable direct root logins completely ... An idea we return to in the text.
pam_wheel	auth, account	Used by programs like su, this module allows root access only if the requesting user is a member of the group called wheel. (Historical note: The use of "wheel" to refer to a privileged group goes back a very long way. It was certainly in early versions of Unix, and according to The Jargon File (http://www.catb.org/jargon/index.html) it comes from the Twenex operating system in the 1960s. But I still have no idea why it is called "wheel".)
pam_winbind	auth	Authenticates users against a Windows domain by talking to the winbind daemon (which in turn talks to the windows domain controller). This is an important component if you're integrating Linux systems into an existing Windows infrastructure, and you want to maintain a common account database across the two.
pam_nologin	auth, account	Prevents users (other than root) from logging in to the system when the file /etc/nologin exists. In some distros, this file is created by the shutdown program to prevent users logging in when the system is about to be stopped.