LinuxSecurity.com
Share your story
The central voice for Linux and Open Source security news
Home News Topics Advisories HOWTOs Features Newsletters About Register

Welcome!
Sign up!
EnGarde Community
Login
Polls
What is the most important Linux security technology?
 
Advisories
Community
Linux Events
Linux User Groups
Link to Us
Security Center
Book Reviews
Security Dictionary
Security Tips
SELinux
White Papers
Featured Blogs
All About Linux
DanWalsh LiveJournal
Securitydistro
Latest Newsletters
Linux Security Week: October 20th, 2014
Linux Advisory Watch: October 17th, 2014
Subscribe
LinuxSecurity Newsletters
E-mail:
Choose Lists:
About our Newsletters
RSS Feeds
Get the LinuxSecurity news you want faster with RSS
Powered By

  
PAM (Pluggable Authentication Modules)

3. PAM (Pluggable Authentication Modules)

Pluggable authentication modules are at the core of user authentication in any modern linux distribution.

3.1. Why

Back in the good old days of linux, if a program, such as su, passwd, login, or xlock, needed to authenticate a user, it would simply read the necessary information from /etc/passwd. If it needed to change the users' password, it would simply edit /etc/passwd. This simple but clumsy method presented numerous problems for system administrators and application developers. As MD5 and shadow passwords became increasingly popular, each program requiring user authentication had to know how to get the proper information when dealing with a number of different schemes. If you wanted to change your user authentication scheme, all these programs had to be recompiled. PAM eliminates this mess by enabling programs to transparently authenticate users, regardless of how user information is stored.

3.2. What

Quoting from the Linux-PAM System Administrator's Guide: "It is the purpose of the Linux-PAM project to separate the development of privilege granting software from the development of secure and appropriate authentication schemes. This is accomplished by providing a library of functions that an application may use to request that a user be authenticated." With PAM, it doesn't matter whether your password is stored in /etc/passwd or on a server in Hong Kong. When a program needs to authenticate a user, PAM provides a library containing the functions for the proper authentication scheme. Because this library is loaded dynamically, changing authentication schemes can be done by simply editing a configuration file.

Flexibility is one of PAM's greatest strengths. PAM can be configured to deny certain programs the right to authenticate users, to only allow certain users to be authenticated, to warn when certain programs attempt to authenticate, or even to deprive all users of login privileges. PAM's modular design gives you complete control over how users are authenticated.

3.2.1. Distributions that support pam.

Nearly all popular distributions have supported PAM for some time. Here's an incomplete list of distributions that support PAM:

  • Redhat since version 5.0

  • Mandrake since 5.2

  • Debian since version 2.1 (partial support in 2.1 -- complete support in 2.2)

  • Caldera since version 1.3

  • Turbolinux since version 3.6

  • SuSE since version 6.2

This list is certainly incomplete and possibly inaccurate. I'd appreciate it if you sent any corrections or additions to this list to .

3.2.2. Installing PAM

Installing PAM from scratch is long process, beyond the scope of this HOWTO. If PAM isn't installed on your system, you're probably running such an old version of your distribution that there are many other reasons to upgrade. If you really want to do it yourself, then you're certainly not the sort of person who needs any help from me. For all these reasons, I'm going to assume that you already have PAM installed.

3.3. How

Enough talk, let's dig in.

3.3.1. PAM configuration files

PAM configuration files are stored in the /etc/pam.d/ directory. (If you don't have /etc/pam.d/ directory, don't worry, I'll cover that in the next section) Let's go over there and take a look.

  ~$ cd /etc/pam.d
  /etc/pam.d/$ ls
  chfn	chsh	login	other	passwd	su	xlock
  /etc/pam.d/$ 
  

Your system may have a few more or a few less files in this directory, depending on what's installed on your system. Whatever the details, you probably saw a file for each of the programs on your system that authenticate users. As you probably already guessed, each file contains the PAM authentication configuration for the program it's named after (except for the other file, which we'll talk about in a little bit). Let's take a look the PAM configuration file for login (I've condensed the file for the sake of simplicity):

  /etc/pam.d/$ cat login
  # PAM configuration for login
  auth       requisite  pam_securetty.so
  auth       required   pam_nologin.so
  auth       required   pam_env.so
  auth       required   pam_unix.so nullok
  account    required   pam_unix.so
  session    required   pam_unix.so
  session    optional   pam_lastlog.so
  password   required   pam_unix.so nullok obscure min=4 max=8
  

Before I dig into this file, I must mention a little something.

3.3.2. A little something

A small percentage of the readers are probably thinking, "Oh no! I don't have a /etc/pam.d directory! Your list of distributions says that my distribution includes PAM, but I can't find that directory. Without PAM, my life is empty and meaningless! What can I do?" Don't worry, all is not lost. If you know that your distribution includes PAM, but you have no /etc/pam.d/ directory, then your PAM configuration is stored in /etc/pam.conf. Rather than being spread across several files, all your PAM configuration is stored in a single file. This adds a little twist to PAM configuration, but the proper adjustments are pointed out in section 3.3.4.

3.3.3. Configuration syntax

PAM configuration files have the following syntax:

  type  control  module-path  module-arguments
  

Using the login configuration file (see above) as an example let's take a look a the syntax for PAM configuration files:

PAM configuration tokens

type

The type token tells PAM what type of authentication is to be used for this module. Modules of the same type can be "stacked", requiring a user to meet multiple requirements to be authenticated. PAM recognizes four types:

account

Determines whether the user is allowed to access the service, whether their passwords has expired, etc.

auth

Determines whether the user is who they claim to be, usually by a password, but perhaps by a more sophistcated means, such as biometrics.

password

Provides a mechanism for the user to change their authentication. Again, this usually their password.

session

Things that should be done before and/or after the user is authenticed. This might included things such as mounting/unmounting the user home directory, logging their login/logout, and restricting/unrestricting the services available to the user.

In the login config file, we see at least one entry for each type. Since this the program that allows user to login (hence the name :), it's understandable that it needs to access all of the different types of authentication.

control

The control token tells PAM what should be done in if authentication by this module fails. PAM recognizes four control types:

requisite

Failure to authenticate via this module results in immediate denial of authentication.

required

Failure also results in denial of authentication, although PAM will still call all the other modules listed for this service before denying authentication.

sufficient

If authentication by this module is successful, PAM will grant authentication, even if a previous required module failed.

optional

Whether this module succeeds or fails is only significant if it is the only module of its type for this service.

In the configuration file for login, we see nearly all of the different control types. Most of the required modules are pam_unix.so (the main authentication module), the single requisite module is pam_securetty.so (which makes sure the user is logging in on a secure console), and the only optional module is pam_lastlog.so (the module that retrieves information on the user's most recent login).

module-path

The module-path tells PAM which module to use and (optionally) where to find it. Most configurations only contain the module's name, as is the case in our login configuration file. When this is the case, PAM looks for the modules in the default PAM module directory, normally /usr/lib/security. However, if your linux distribution conforms to the Filesystem Hierarchy Standard (FHS), PAM modules can be found in /lib/security.

module-arguments

The module-arguments are arguments to be passed to the module. Each module has its own arguments. For example, in our login configuration, the "nulok" ("null ok", argument being passed to pam_unix.so module, indicating the a blank ("null") password is acceptable ("ok").

3.3.4. pam.conf configuration

If your PAM configuration is stored in /etc/pam.conf rather than /etc/pam.d/, PAM configuration lines are a bit different. Rather than each service having its own configuration file, all configurations are stored in /etc/pam.conf with the service name as the first token in a configuration line. For example, the following line in /etc/pam.d/login:

    auth       required   pam_unix.so nulok
    

would become the following line in /etc/pam.conf:

    login	auth       required   pam_unix.so nulok
    

Except for this minor difference, all the rest of the configuration PAM syntax applies.

3.4. Getting more information

For more information on configuring PAM and complete PAM module reference, consult the Linux-PAM System Administrator's Guide. This guide serves as a thorough and up-to-date reference on PAM configuration.

    
Partner

 

Latest Features
Peter Smith Releases Linux Network Security Online
Securing a Linux Web Server
Password guessing with Medusa 2.0
Password guessing as an attack vector
Squid and Digest Authentication
Squid and Basic Authentication
Demystifying the Chinese Hacking Industry: Earning 6 Million a Night
Free Online security course (LearnSIA) - A Call for Help
What You Need to Know About Linux Rootkits
Review: A Practical Guide to Fedora and Red Hat Enterprise Linux - Fifth Edition
Yesterday's Edition
USB is now UEC (use with extreme caution)
iPhone Encryption and the Return of the Crypto Wars
Partner Sponsor

Community | HOWTOs | Blogs | Features | Book Reviews | Networking
 Security Projects |  Latest News |  Newsletters |  SELinux |  Privacy |  Home
 Hardening |   About Us |   Advertise |   Legal Notice |   RSS |   Guardian Digital
(c)Copyright 2014 Guardian Digital, Inc. All rights reserved.