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

Feature: Security

Let PAM take care of GNU/Linux security for you

By Federico Kereki on October 14, 2008 (9:00:00 AM)

Share    Print    Comments   

When they hear the word PAM, most people think of a certain blonde Canadian Playmate, but readers of this Web site surely will recognize the basic element of Linux security: the Pluggable Authentication Modules. So let's talk about how this PAM works, and look at some examples of how it is used.

If each Linux program had to include its own authentication logic, we'd go crazy. How could you trust that all your applications implemented the same checks? And how could you implement extra controls?

PAM gives us a simple alternative: if a program needs to authenticate a user, it can call the PAM application programming interface, and that API will take care of running whatever checks you need, according to whatever rules you specify in your PAM configuration files. You can even modify your authentication mechanisms on the fly, and all PAM-aware applications will automatically start using the new authentication method.

Want to use biometric controls, such as fingerprint readers or iris scanners? If the hardware maker provides a PAM, you are set; you just have to include that module in your configuration files, and from that point on your new device will be available for all applications.


The PAM library provides four distinct areas:

  • auth has to do with user identification, for example through entering a user name and password
  • account deals with account limitations; given that the user is a valid one, what is he allowed to do?
  • session manages connection management, including logging, for example.
  • password has to do exclusively with password-related functions.

For each application that will use PAM, you need a configuration file in the /etc/pam.d directory. Your login configurations go in the /etc/pam.d/login file. (There is another, older, method that uses just a single /etc/pam.conf file, but it is rarely used these days.) You need to define which modules will be applied for each group, creating a "stack" of actions. Whenever a request is processed, the PAM library starts running through the modules in the appropriate stack. Depending upon the modules' output, the user request will either be granted or denied.

To make this happen correctly, you need to select whether any given module is mandatory or optional, according to the following list:

  • A requisite module must return "success" to keep the process going. If such a module fails, the PAM library will return "failure," and won't run any more modules in the stack.
  • A required module is also mandatory, but if it fails, though the PAM API will still return "failure," the rest of the modules in the same stack will still run.
  • If a sufficient module succeeds, the PAM library will immediately return "success" without running any other modules.
  • Finally, optional modules can succeed or fail; approval will be given depending upon whether any module eventually succeeds.

The PAM configuration files themselves are simple. Comments start with a hash character ("#"). Long lines can be continued by ending them with a backslash ("\"). Other lines have three fields: the context area (auth, account, session, or password); the control flag (requisite, required, sufficient, or optional); and the path to the module that will be run, along with any possible parameters. (Actually, the second field can be more complicated, but we'll skip those details here. Also, you can also use "include," as in "auth include common-account," to include rules from another text file.)

For default values, there is a special service named "other" whose rules are automatically applied for any application without a specific configuration file. The safest setup for this file to deny all requirements (module takes care of that) and send a warning to the administrator (via module

# # default; denying everything is the safest way # auth required auth required account required password required password required session required

You could substitute for and then the standard authentication method (user and password) would be applied. (And if you don't care about security, substitute instead, and all requests will be accepted -- but don't say you weren't warned!) For security concerns, give a quick look at the /etc/pam.d directory, and rename any configuration files for applications you don't use, thus making sure the "other" configuration will apply; should you decide you need an application again, just rename the configuration back to its original name.

Available modules

There's no canonical list of modules, but it's a safe bet that you are likely to bump into at least some of the ones listed below. You can usually find PAM modules at /lib/security (/lib64/security for 64-bit versions) though some distributions opt for /usr/lib/security. If you want more detailed information, try running man theNameOfThePAM.

  • pam_unix and pam_unix2 provide classic Unix-style authentication based on the /etc/passwd and /etc/shadow files. You can also use pam_userdb for validation against a Berkeley database.
  • pam_time lets you restrict access to services depending on the day of the week and the current time based on file /etc/security/time.conf.
  • pam_access allows or denies access according to rules in /etc/security/access.conf. Whenever a user tries to log in, rules are scanned sequentially, and permission is conceded or refused depending on the first matching rule. Another way of doing this is with pam_succeed_if, which lets you check for specific desired account characteristics, such as belonging to a certain group.
  • pam_listfile provides yet another way of allowing or denying services based on the contents of a file. For example, you can limit sshd access by creating a list of approved users (let's call it /etc/ssh_users) and including auth required item=user sense=allow file=/etc/ssh_users onerr=fail in /etc/pam.d/sshd.
  • pam_deny and pam_permit also have to do with access; the first module always denies access, while the second one accepts everybody (careful!). More drastically, pam_nologin blocks all logins if file /etc/nologin exists
  • pam_echo and pam_motd allow showing messages to the user; the first one shows any file, and the second shows the "message of the day" file. Similarly, pam_lastlog shows the date and time of the user's last login, and pam_mail tells him if he has mail.
  • pam_limits lets you specify limits on system resources, per file /etc/security/limits.conf.
  • pam_rootok allows the root user access without further checks. This usually appears in /etc/pam.d/su, so root will be able to act as any other user, without any password. You need include auth sufficient to achieve this. A way to allow, but limit, su usage is with pam_wheel, which provides root access only to members of group "wheel." You must include auth required in order to force this check.
  • pam_cracklib and pam_pwcheck provide checks for password strength. (See below.)
  • pam_warn just registers login information in the system log.

You can even roll your own modules, but you will probably only need those mentioned above or the ones in this list.

Safe passwords

In another article, we saw how to use PAM to secure a remote connection by using pam_access. (Another possibility would have been using pam_listfile.) Now let's turn to another example -- and figure out how to make users pick good passwords.

If it were up to users, most would just skip passwords altogether, while some sysadmins might like them to change their passwords daily. Without going to extremes, you can use PAM to enforce reasonably good password practices. To do this, you need to edit the "password" stack in /etc/pam.d/passwd so that your controls will be executed whenever users try to change their passwords by using either pam_cracklib or pam_pwcheck. Both have similar functions, including:

  • rejecting passwords that are too short, by specifying the minlen parameter.
  • forbidding passwords that were used before, or that are too similar to the previous one.
  • forbidding new passwords that are the same as the previous one, only with case changes (so "LiNuX" is out if earlier you had "liNUx").
  • rejecting rotated or backwards-written previous passwords (so you cannot use "comlinux" if you previously used "linuxcom").
  • forcing the user to include uppercase characters, non-alphabetic symbols, or numbers in the new password.

You can even specify the cracklib parameter to use the cracklib library to reject dictionary-found keywords. A possible /etc/pam.d/passwd file could be:

# # The user is given three opportunities to enter a strong password. # The password needs be at least 6 characters long, with at least # two digits, one uppercase letter, and one non-alphabetic character, # and any number of lowercase letters. # password required retry=3 minlen=6 dcredit=-2 ucredit=-1 ocredit=-1 lcredit=0 # # Using use_authtok in the pam_unix module ensures it doesn't prompt # for a password on its own, but uses the one provided by pam_cracklib # instead. The pam_cracklib module doesn't store passwords (only # checks them) so we need the standard pam_unix module in order to # accomplish that. # password required use_authtok

Check the pam_cracklib documentation for even more options.

PAM usage is the basis for GNU/Linux security, and provides great flexibility. Though PAM configuration isn't quite straightforward (no graphic interfaces here!) it really isn't that hard, and you can greatly enhance your safety by using PAM appropriately.

Federico Kereki is an Uruguayan systems engineer with more than 20 years' experience developing systems, doing consulting work, and teaching at universities.

Share    Print    Comments   


on Let PAM take care of GNU/Linux security for you

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

Let PAM take care of GNU/Linux security for you

Posted by: Anonymous [ip:] on October 14, 2008 10:02 AM
LDAP should also be mentioned here. One can let users authenticate to a LDAP server by using the module LDAP is mainly used for a centralized user authentication server, providing the same UIDs and GID's across a network. More on LDAP: More on integration with PAM:


Let PAM take care of GNU/Linux security for you

Posted by: Anonymous [ip:] on October 14, 2008 05:11 PM
Great article I appreciate the overview and learned something new today. Now where do I want to use this.


Let PAM take care of GNU/Linux security for you

Posted by: Anonymous [ip:] on October 14, 2008 11:38 PM
Since you mentioned her, I correctly guessed you were talking about Pamela Anderson, but honestly, the first thing that came to my mind was a certain cooking oil that comes out of a spray can. I would think most people would think of that first. Anyway, now that I know what PAM is, I'll be looking into it further, to see how you can integrate fingerprint readers and such, and use it's services for specific applications. Thanks for the article.


Let PAM take care of GNU/Linux security for you

Posted by: Anonymous [ip:] on October 15, 2008 08:06 AM
Personally I don’t like pam_cracklib and I would preferred pam_passwdqc.


PAM, when done right, is very handy indeed

Posted by: Anonymous [ip:] on October 15, 2008 06:34 PM
I do use this, both with LDAP and with TACACS+ (the pam_tacplus module). It is very, very nice for centralizing authentication.

To answer the second poster's question of where you'd wnat to use this, here's how I do it. I have a bunch of GNU/Linux boxes out at various sites at work. As we know, each has its own /etc/passwd and /etc/shadow, and thus, changing a password or disabling an account becomes tedious. With PAM on these end-stations pointing to one or more centralized LDAP or TACACS+ authentication server(s), that tedium goes away. At work, I do it against a TACACS+ server, and at home, I use LDAP.

Here's another one. Let's suppose you want to move from MS Windows Active (Craptive?) Directory to a Samba-LDAP backend. No problem, that's built into Samba, so you have your PDC/BDC setup done there. But wait, you now also want to convert at least some of your end stations from, say, Windows XP to GNU/Linux. Naturally, you want to maintain single-sign-on for GNU/Linux end stations like you have the MS Windows end stations. Maybe you even want to do LTSP against that LDAP server. PAM is what makes that happen.

Here's a third. Say you have your Apache server, and you'd like for it to authenticate against /etc/passwd and /etc/shadow. One way to do this is to allow the Apache process to read /etc/shadow. Well, that's a bad idea from a security perspective. Much better to have Apache go through PAM. Furthermore, this is how you can get Apache to authenticate against LDAP.

So, this has a lot of uses, and it's highly recommended for enterprise environments. Some (like Pat Volkerding of Slackware fame) don't like it, and he's made clear why. Others say, a *correctly configured* PAM is just as secure as doing things the traditional way and gives you way more flexibility. I've come to agree with the latter.

BTW, yes, the first thing I thought of was the cooking oil, too. :-)


Crude references

Posted by: Anonymous [ip:] on October 16, 2008 01:21 AM
First thing I thought of was a relative whose first name is Pam. I didn't know Pam Anderson was a playmate or Canadian. And if I wasn't related to a Pam, I would've gone with cooking oil too.


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

Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya