This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new!


Understanding PAM

By Brian Jones on February 11, 2004 (8:00:00 AM)

Share    Print    Comments   

Pluggable Authentication Modules (PAM) is an oft misunderstood, and in at least this admin's opinion, underutilized mechanism on *nix systems. Sitting in its little corner of the /etc directory, PAM sits overlooking its configuration files and man pages, just waiting for someone to come along and discover the power that it can give to administrators and developers alike. When will they realize that PAM is not just for 'Authentication' anymore?

PAM is a collection of modules that essentially form a barrier between a service on your system, and the user of the service. The modules can have widely varying purposes, from disallowing a login to users from a particular UNIX group (or netgroup, or subnet...), to implementing resource limits so that your 'research' group can't hog system resources.

PAM is used by major commercial UNIX flavors such as AIX, HP-UX and Solaris, as well as the major free versions of UNIX, like FreeBSD. Almost all distributions of Linux also implement PAM, though I believe Slackware is still the one notable holdout in this area.

The power, flexibility and ubiquity of PAM is a boon for developers of Linux applications, since instead of writing a full-fledged authentication layer for their program, they can simply write a hook into PAM, and administrators can configure it along with the rest of the system services using PAM. This, in turn, makes the lives of administrators much easier, since we only have to learn PAM, instead of learning and trying to remember a separate configuration model for every system we decide to run.

How to Read A Config File

I'll be looking at pam as it applies to Linux systems. Solaris and other commercial UNIX systems have a slightly different configuration model, centered around a single file, /etc/pam.conf. Though conceptually the two implementations are just about identical, the Linux model uses a different configuration file for each service which uses PAM. On most Linux systems, these configuration files live in /etc/pam.d, and are named after the service - for example, the 'login' configuration file is called /etc/pam.d/login. Let's have a quick look at a version of that file:

auth required /lib/security/
auth required /lib/security/
auth sufficient /lib/security/
auth required /lib/security/ try_first_pass
account sufficient /lib/security/
account required /lib/security/
password required /lib/security/
password required /lib/security/
password required /lib/security/ use_first_pass session required /lib/security/

PAM Management Realms

The first thing I'd like you to notice in the file is the leftmost column, which, in all, contains four unique words, which represent four realms of PAM management: auth, account, password and session. While there are many modules which support more than one of these realms (indeed, pam_unix supports all of them), others, like pam_cracklib for instance, are only suited for one (the 'password' facility in pam_cracklib's case). Knowing what these four realms are responsible for is extrememly important if you want to make effective use of PAM. Below is a quick explanation of how I tend to think about these keywords in practice:

The 'auth' realm (I call it a realm - the docs refer to it as a 'management group' or 'facility') is responsible for checking that the user is who they say. The modules that can be listed in this area generally support prompting for a password.
This area is responsible for a wide array of possible account verification functionality. There are many modules available for this facility. Constraints to the use of a service based on checking group membership, time of day, whether a user account is local or remote, etc., are generally enforced by modules which support this facility.
The modules in this area are responsible for any functionality needed in the course of updating passwords for a given service. Most of the time, this section is pretty 'ho-hum', simply calling a module that will prompt for a current password, and, assuming that's successful, prompt you for a new one. Other modules could be added to perform password complexity or dictionary checking as well, such as that performed by the pam_cracklib and pam_pwcheck modules.
Modules in this area perform any number of things that happen either during the setup or cleanup of a service for a given user. This may include any number of things; launching a system-wide initialization script, performing special logging, mounting the user's home directory, or setting resource limits.
PAM Module Controls

The middle column holds a keyword that essentially determines what PAM should do if the module either succeeds or fails. These keywords are called 'controls' in PAM-speak. Note that this keyword is not an indicator to the module, but to the underlying PAM library. In probably 90% of the cases, you can use one of the common keywords (requisite, required, sufficient or optional). However, this is only the tip of the iceberg in terms of unleashing the flexibility and power of PAM. You could actually use more complicated syntax to account for seemingly any situation. Here are the valid simple 'one-word' keywords PAM understands:

If a 'required' module returns a status that is not 'success', the operation will ultimately fail, but only after the modules below it are invoked. This seems senseless at first glance I suppose, but it serves the purpose of always acting the same way from the point of view of the user trying to utilize the service. The net effect is that it becomes impossible for a potential cracker to determine which module caused the failure - and the less information a malicious user has about your system, the better. Important to note is that even if all of the modules in the stack succeed, failure of one 'required' module means the operation will ultimately fail. Of course, if a required module succeeds, the operation can still fail if a 'required' module later in the stack fails.
If a 'requisite' module fails, the operation not only fails, but the operation is immediately terminated with a failure without invoking any other modules: 'do not pass go, do not collect $200', so to speak.
If a sufficient module succeeds, it is enough to satisfy the requirements of sufficient modules in that realm for use of the service, and modules below it that are also listed as 'sufficient' are not invoked. If it fails, the operation fails unless a module invoked after it succeeds. Important to note is that if a 'required' module fails before a 'sufficient' one succeeds, the operation will fail anyway, ignoring the status of any 'sufficient' modules.
An 'optional' module, according to the pam(8) manpage, will only cause an operation to fail if it's the only module in the stack for that facility.
Stacking Modules

In the rightmost column we see the actual path to the module that gets invoked. Note that in our sample config, four separate modules are listed for the 'auth' realm. This is referred to as 'stacking' in PAM lingo. If you're thinking that this implies that ordering of the stacked modules is significant, you're right. Also, in addition to the more complex options you can pass to the PAM library in the center column, there are, likewise, options that you can feed to the module itself. This can be seen in our example config file, where the module takes the 'try_first_pass' argument. Furthermore, many modules are meant to be used with an accompanying configuration file of some sort, allowing for more complex options that would make the PAM config file a big mess otherwise.

Drilling Down: What's Going On?

Now that we have a grip on how to basically parse a configuration file at a high level, let's drill down and see exactly what's going on in our example file. We'll have a look at the module stack for the 'auth' realm, detailing what will happen given a number of scenarios.

In our example file, we have four modules stacked for the auth realm:

auth       required     /lib/security/
auth       required     /lib/security/
auth       sufficient   /lib/security/
auth       required     /lib/security/ try_first_pass

As the modules are invoked in order, here is what will happen:

  1. The 'pam_securetty' module will check its config file, /etc/securetty, and see if the terminal being used for this login is listed in the file. If it's not, root logins will not be permitted. If you try to log in as root on a 'bad' terminal, this module will fail. Since it's 'required', it will still invoke all of the modules in the stack. However, even if every one of them succeeds, the login will fail. Interesting to note is that if the module were listed as 'requisite', the operation would terminate with a failure immediately, without invoking any of the other modules, no matter what their status.
  2. The 'pam_env' module will set environment variables based on what the administrator has set up in /etc/security/pam_env.conf. On a default setup of Redhat 9, Fedora Core 1, and Mandrake 9.2, the configuration file for this module doesn't actually set any variables. A good use for this might be automatically setting a DISPLAY environment variable for a user logging in via SSH so they don't have to set it themselves if they want to shoot an 'xterm' back to their remote desktop (though this can be taken care of by OpenSSH automagically).
  3. The 'pam_ldap' module will prompt the user for a password, and then check the ldap directory indicated in /etc/ldap.conf to authenticate the user. If this fails, the operation can still succeed if 'pam_unix' succeeds in authenticating the user. If pam_ldap succeeds, 'pam_unix' will not be invoked.
  4. The 'pam_unix' module, in this case, will not prompt the user for a password. The 'try_first_pass' argument will tell the module to use the password given to it by the preceding module (in this case, pam_ldap). It will try to authenticate the user using the standard getpw* system calls. If pam_unix fails, and pam_ldap has failed, the operation will fail. If pam_ldap fails, but pam_unix succeeds, the operation will succeed (this is extremely helpful in cases where root is not in the ldap directory, but is still in the local /etc/passwd file!).

Depending on the feedback and corrections submitted for this article, I'm happy to go into PAM further or with some other focus in a future article. If you've done something amazing with PAM or notice a common problem users have with PAM that hasn't been discussed here, please send me email (njcajun - linuxlaboratory dot org) or post a comment.

Share    Print    Comments   


on Understanding PAM

Note: Comments are owned by the poster. We are not responsible for their content.

Re:PAM modules

Posted by: njcajun on February 16, 2004 01:40 AM
Sounds like some of what you want is available - but not through PAM. And the reason it's not done through PAM is because... well... it's already being done well enough by some other tool, so nobody bothered to make a module for it.

Anything having to do with logging is a good example. logrotate, and syslog have the needs of most admins covered, and it's a little tough to see the usefulness of putting this in PAM, since most applications already have a logging interface that is easy to write and easily configurable by and admin. The idea of PAM is to allow developers to write a PAM interface (which is simple) so that admins can configure authentication/session restraints as they see fit (also pretty simple).

You're right in saying that PAM is NOT a 'security system'. It's only ONE PART of a system's security. You cannot simply configure PAM and say 'ok, all locked down'. It's not that simple, and it's never been a goal of anyone's to MAKE it that simple. Look into tools like tcpwrappers, bastille, tripwire, the compat libs, the iptables manpage, and the documentation for the latest kernel (all of it.. no - really). Everything you want to do is available. However, it's not all under the PAM umbrella. Nor does any admin want it to be, since building interfaces for firewalls, logging config, system password constraints, file access controls, etc., would make PAM the 'windows registry' of the Linux world. Too much responsibility is not good, and antithetical to the UNIX mantra of 'do one thing, and do it well'.

There are some other things you said that I don't think are factual. For example, 'blocking after x number of attempts' is possible already - though possibly not for all modules. Forcing password changes is also possible already with PAM. Forcing a specific sequence of password requirements is pretty much there - have a look at using pam_cracklib with pam_pwcheck. In my environment, we still had a little code to write to enforce everything we wanted (ie, you have to use a number, and it can't be the first or last character in the password), but it did a lot of jobs we were doing with code before.

Your items numbered 7 and 8 about using a different password algorithm should be available through bastille. ]

I'd write more, but I do have to run...

All of this said, I'll most likely be covering some of the above mentioned tools in future articles.<nobr> <wbr></nobr>:)


Re:PAM modules

Posted by: Administrator on February 17, 2004 10:35 PM
Thanks for the reply.

There are 4 main things in security that we have to meet.

1. Login Attempts : lock out people after X number of tries.
2. Logs of password changes, logins, I/O accesses, and invalid permission file accesses.. even just looking at a file. Specific files that have to be logged are passwd, shadow, etc..
3. Banners before logins to be bypassed with a click of some sort. The banners specify the security level of the system.
4. Forced change of passwords every 6 months.

PAM w/Snare was able to accomplish 1,2,4. The Banner was configuration items in X and the getty's.

PAM was good for many things. In the end, as you said, it was PART of the solution.


Re:PAM modules

Posted by: Administrator on February 13, 2004 09:24 AM
I agree! This article was well written and provided much needed info. Unfortuanately, it felt like a good movie that left you hanging in the end. I need more.




PAM modules

Posted by: Administrator on February 12, 2004 11:25 PM
Thanks, This helps! The documentation for PAM is a bit to scattered and cryptic. I would like to see more about the available modules. Thanks Again.


Re:PAM modules

Posted by: Administrator on February 15, 2004 02:54 AM
I have had to meet the security requirements of various institutions and use PAM to meet many of the basic logging requirements.

There are several issues I would wish addressed.

1. There are several conflicts I found in using the module options for number of logins before you kick people out. If you include root, it has trouble working.
2. Pam is only as good as its supporting functions. Turning on logging, quotas, authentication of passwords, etc are useless without a way DESCRIBED in detail on how to disable or reenable these items.
3. File Access is not covered. Had to use SNARE and its still incomplete.
4. PAM is not a security system.. and yet it is. It is an incomplete one.. How do I make it work for things like:
Common Criteria Certification (Redhat Interprise is Cert)
EAL level 3 Certification (SuSE is cert)

1. Logging
2. Blocking after X number of attempts
3. Turning over logs after X number of days (logrotate)
4. Putting a banner before all Logins stating a notice of some sort.
5. Forced a change password after X logins, or X time.
6. FORCE a SPECIFIC sequence of Password requirements (numberics, alpha, etc)
7. Force more than 8 significant letters for the password.
8. Be able to drop in a DIFFERENT algorithm for passwords that will work with Shadow/Passwd. There are specific new algorithms that are required in some contracts that give 1024 bit encryption, etc.

This is a start of a super powerful document. I got tired of sifting through the documentation on the net.. a strong, tested, primer that not only showed the Capabilities of PAM but also the Limitations. As you can see, I am trying to use it for things that logrotate, chkpasswd, or other functions use.


This story has been archived. Comments can no longer be posted.

Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya