PAM (Pluggable authentication modules)

PAM (the Pluggable Authentication Module) is a unified authentication scheme introduced by Sun in Solaris (released as an undocumented feature in Solaris 2.3 ) and later re-implemented in other commercial Unixes and most open source OSes (BSD variants, Linux, etc).  PAM permits modularization (plus some refactoring) of the old codebase.  In old versions of Unix the authentication code was not modular and was imbedded in login, su, passwd and all the other programs that perform authentication. If you wanted to make any change to the database in which passwords were stored, or change the ground rules for how authentication was done, you had to modify and rebuild all those programs.

It is rather primitive system  which can now be a textbook example of the danger of inventing ad hoc languages.  In Linux complexity of PAM (over-complexity to be exact) exceeds the ability of regular administrators to understand it by large margin. As such from a pretty straightforward security measure Linux PAM mutated into a something in between a security mechanism and a security hole.

This is  especially true if you try to change something without understanding of complex interplay between modules (can we envision appearance "Linux PAM specialist" in job adds ?). Also PAM include files is classic example of road to hell paved with good intensions: they provide additional capability for intruder to hijack access to the system in a way that is very difficult to detect.  Just try to answer the questions below for any Linux system:

• Which PAM module controls the ability of the user to reset password and which the complexity of the new password ?

• Which PAM module controls the behavior of accounts with null passwords (which should be consider to be disabled).

• Which module is should be disabled if we add SecurID authentication to the mix for ftp and telnet.

• Which module can be used to control the ability of the user to switch to root ?

• Which module can be used to control the value of UID for blocking user from authenticating  ?

Converting this mess to a scripting language probably can improve things but it might be too late for linux with its pretty mature level of distributions and old age of OS itself.

But even with all its warts PAM was a big improvement over previous situation: it allows the system administrator to customize the authentication services that should be used for various applications.  At the core of PAM is a primitive ad-hoc assembler like PAM language that is used to connect (stack) several authentication modules, each of which can perform certain checks. A Sun original  rfc86.0 document describes it (it is slightly outdated).   You can also decide if success of the check is enough for authentication, if the failure of the check is enough for rejection and some other simple logical tests. 

PAM is configured by making appropriate modifications to one file, /etc/pam.conf (Solaris), or by editing individual control files that are located in /etc/pam.d in Linux.   Linux re-implementation of PAM is described at the Official Linux-PAM home page 

PAM allows you to change your authentication methods and requirements on the fly, and encapsulate all local authentication methods without recompiling any of your binaries.

Despite being primitive from the point of view of its the underling formal language (simple rules) the system itself is very tricky as there are a lot of behind the surface information that you need to understand.  Just look at the problem of integrating of RSA SecurID into this framework. The best way is to look for help at forums like Red Hat The pam-list Archives

The applications (typically login, ftp, dtlogin, SSH and other programs that "log a user in") are now all built to be aware of the services PAM offers -- i.e. the corresponding daemons and program knows how to get PAM to do the authentication.

PAM the authentication modules are implemented as dynamically-linked shared library files. A single standard API is used by all authentication programs, and a configuration file read at run time determines which authenticators are actually used for each program. Thus you can revise how authentication works by just installing new modules and or editing the configuration files. You don't need to rebuild the application programs.

The PAM config file formats for Linux and Solaris PAM are slightly different, and the names of the standard modules are entirely different. There are portability issues involved in writing PAM modules as well. Things to be aware of:

• As dynamically-linked libraries, PAM modules have the same access rights as the calling program. For example, a PAM module for authenticating from a shadow password file which as only readable by root, will always fail if the calling program is not running as root.
   
• The third argument the pam_start() is a pointer to a struct pam_conv. This structure contains a pointer to the conversation function, and a void application data pointer. You are supposed to be able to use the application data pointer to pass information through to the conversation function. In the Solaris 2.6 version of PAM, this does not work. The application data passed to the conversation function will be NULL no matter what you set in the conversation structure that you pass to pam_start. This does work correctly in Linux-PAM and Solaris 7 PAM.
   
• The RFC specifies the syntax of the pam_strerror() function as:

       char *pam_strerror(int errnum);

  Versions of Linux-PAM before 0.59 implemented it this way. However, no Solaris versions do, and later versions of Linux-PAM have changed too. It is now:

       char *pam_strerror(pam_handle_t *pamh, int errnum);

Typical additional things that you do with PAM is:

• To enforce a particular structure of the password (for example no less then two digits and one special character). This is similar to npasswd capabilities.
   

• Linux can be configured to imitate properties of the wheel group in BSD. This group provides an additional protection against normal users trying to su to root. It is not available on Solaris, AIX and HP-UX.  The default PAM setting on Gentoo distribution requires that a user be a member of the group "wheel" in order to be able to su to root. That configuration can be replicated on Red Hat and Suse.

In addition to the lines described below, there are two special characters provided for the convenience of the system administrator: comments are preceded by a "#" and extend to the next end-of-line; also, module specification lines may be extended with a "\"-escaped newline.

If the PAM authentication module (loadable link library file) is located in the default location, then it is not necessary to specify the path. In the case of Linux, the default location is /lib/security. If the module is located outside the default, then the path must be specified as:

auth  required  /other_path/pam_strange_module.so

Anatomy of /etc/pam.d Entries

A general configuration line of the /etc/pam.conf file has the following form:

service-name   module-type   control-flag   module-path   args

We explain the meaning of each of these tokens. The second (and more recently adopted) way of configuring Linux-PAM is via the contents of the /etc/pam.d/ directory. Once we have explained the meaning of the tokens, we describe this method.

service-name The name of the service associated with this entry. Frequently, the service-name is the conventional name of the given application for example, ftpd, rlogind and su, and so on.

There is a special service-name reserved for defining a default authentication mechanism. It has the name OTHER  and may be specified in either lower- or uppercase characters. Note, when there is a module specified for a named service, the OTHER  entries are ignored.

module-type

One of (currently) four types of module. The four types are as follows:

• auth: Provides authentication for users and enables credentials to be set, refreshed, or destroyed. It establishes that the user is who he or she claims to be by prompting the user for a password or other means of identification. In Linux it also can grant group membership (independently of the /etc/groups file) or other privileges through its credential-granting properties.
• account: Checks for password aging, account expiration, and access restrictions.  It is typically used to restrict/permit access to a service based on the time of day, currently available system resources (maximum number of users), or perhaps the location of the user login. For example, the "root" login may be permitted only on the console, ssh can be permitted only to members of group wheel, etc. 
• session:   Manages the opening and closing of a session, for example updating lastlog file. Can do things before and after he or she can be given service... 
• password: This is module for password management. It is required so that user can change expired password during the particular session (telnet, SSH, etc) and provides capabilities for updating the authentication token associated with the user (typically a password). Typically, there is one module for each "challenge/response" authentication (auth) module type.

control-flag

 The control-flag is used to indicate how the PAM library will react to the success or failure of the module it is associated with. Since modules can be stacked (modules of the same type execute in series, one after another), the control-flags determine the relative importance of each module. The application is not made aware of the individual success or failure of modules listed in the /etc/pam.conf file. Instead, it receives a summary success or fail response from the Linux-PAM library. The order of execution of these modules is that of the entries in the /etc/pam.conf file; earlier entries are executed before later ones. As of Linux-PAM v0.60, this control-flag can be defined with one of two syntaxes. The simpler (and historical) syntax for the control-flag is a single keyword defined to indicate the severity of concern associated with the success or failure of a specific module. There are four such keywords: required, requisite, sufficient, and optional.

The Linux-PAM library interprets these keywords in the following manner:

• required: This indicates that the success of the module is required for the module-type facility to succeed. Failure of this module will not be apparent to the user until all of the remaining modules (of the same module-type) have been executed.
• requisite: Like required, except that if such a module returns a failure, control is directly returned to the application. The return value is that associated with the first required or requisite module to fail. This flag can be used to protect against the possibility of a user getting the opportunity to enter a password over an unsafe medium. It is conceivable that such behavior might inform an attacker of valid accounts on a system. This possibility should be weighed against the not insignificant concerns of exposing a sensitive password in a hostile environment.
• sufficient: The success of this module is deemed sufficient to satisfy the Linux-PAM library that this module-type has succeeded in its purpose. In the event that no previous required module has failed, no more "stacked" modules of this type are invoked. (In this case, subsequent required modules are not invoked). A failure of this module is not deemed as fatal to satisfying the application that this module-type has succeeded.
• optional: As its name suggests, this control-flag marks the module as not being critical to the success or failure of the user's application for service. In general, Linux-PAM ignores such a module when determining if the module stack will succeed or fail. However, in the absence of any definite successes or failures of previous or subsequent stacked modules, this module will determine the nature of the response to the application. One example of this latter case is when the other modules return something like PAM_IGNORE.

The more elaborate (newer) syntax is much more specific and gives the administrator a great deal of control over how the user is authenticated. This form of the control-flag is delimited with square brackets and consists of a series of value=action  tokens:

[value1=action1 value2=action2 ...]

Here, value1 is one of the following return values:

success; open_err; symbol_err; service_err; system_err; buf_err;
perm_denied; auth_err; cred_insufficient; authinfo_unavail;
user_unknown; maxtries; new_authtok_reqd; acct_expired; session_err;
cred_unavail; cred_expired; cred_err; no_module_data; conv_err;
authtok_err; authtok_recover_err; authtok_lock_busy;
authtok_disable_aging; try_again; ignore; abort; authtok_expired;
module_unknown; bad_item; and default.

The last of these (default) can be used to set the action for those return values that are not explicitly defined.

The action1 can be a positive integer or one of the following tokens: ignore; ok; done; bad; die; and reset. A positive integer, J, when specified as the action, can be used to indicate that the next J modules of the current module-type will be skipped. In this way, the administrator can develop a moderately sophisticated stack of modules with a number of different paths of execution. Which path is taken can be determined by the reactions of individual modules.

• ignore: When used with a stack of modules, the module's return status will not contribute to the return code the application obtains.
• bad: This action indicates that the return code should be thought of as indicative of the module failing. If this module is the first in the stack to fail, its status value will be used for that of the whole stack.
• die: Equivalent to bad with the side effect of terminating the module stack and PAM immediately returning to the application.
• ok: This tells PAM that the administrator thinks this return code should contribute directly to the return code of the full stack of modules. In other words, if the former state of the stack would lead to a return of PAM_SUCCESS, the module's return code will override this value. Note, if the former state of the stack holds some value that is indicative of a module's failure, this ok value will not be used to override that value.
• done: Equivalent to ok with the side effect of terminating the module stack and PAM immediately returning to the application.
• reset: Clears all memory of the state of the module stack and starts again with the next stacked module.

Each of the four keywords, required; requisite; sufficient; and optional, have an equivalent expression in terms of the new syntax. They are as follows:

• required is equivalent to [success=ok new_authtok_reqd=ok ignore=ignore default=bad].
• requisite is equivalent to [success=ok new_authtok_reqd=ok ignore=ignore default=die].
• sufficient is equivalent to [success=done new_authtok_reqd=done default=ignore].
• optional is equivalent to [success=ok new_authtok_reqd=ok default=ignore].

Just to get a feel for the power of this new syntax, here is a taste of what you can do with it. With Linux-PAM-0.63, the notion of client plug-in agents was introduced. This makes it possible for PAM to support machine-machine authentication using the transport protocol inherent to the client/server application. With the [ ... value=action ... ] control syntax, it is possible for an application to be configured to support binary prompts with compliant clients, but to gracefully fail over into an alternative authentication mode for legacy applications.

module-path

The pathname of the dynamically loadable object file; the pluggable module itself. If the first character of the module path is "/", it is assumed to be a complete path. If this is not the case, the given module path is appended to the default module path: /lib/security (but see the previous notes).

The arguments are a list of tokens that are passed to the module when it is invoked, much like arguments to a typical Linux shell command. Generally, valid arguments are optional and are specific to any given module. Invalid arguments are ignored by a module; however, when encountering an invalid argument, the module is required to write an error to syslog(3). For a list of generic options, see the next section.

If you wish to include spaces in an argument, you should surround that argument with square brackets. For example:

squid auth required pam_mysql.so user=passwd_query passwd=mada \
db=eminence [query=select user_name from internet_service where \
user_name="%u" and password=PASSWORD("%p") and service="web_proxy"]

When using this convention, you can include "[" characters inside the string, and if you wish to have a "]" character inside the string that will survive the argument parsing, you should use "\[". In other words,

[..[..\]..]    -->   ..[..]..

Any line in one of the configuration files that is not formatted correctly will generally tend (erring on the side of caution) to make the authentication process fail. A corresponding error is written to the system log files with a call to syslog(3).

This release supports the core PAM API. There is still some missing functionality, but
it should implement enough of the API for most needs. There is not much in the way
of documentation at this point. If you are familiar with the PAM API, a quick glance
at the sample program should get you going.

• This is an Alpha release.
• This release will have bugs
• This release is probably quite insecure
• You have been warned.
• Enhancements and bug-fixes gladly accepted.

This code is released under the GNU LGPL. Please read the file entitled 'COPYING', which is
part of the tar.gz distribution, if you are unfamiliar with the terms of the GNU Library General
Public License.  

• PyPAM-0.5.0 has been tested with Python 2.3 and 2.4

Changes in version 0.5.0 include:

• Fixed the COPYING file.  It now contains the LGPL 2.1 license as originally intended.
• Converted from autoconf/automake/libtool to Python distutils.
• Added the beginnings of a unit test suite.
• Added "userdata" attachments to the pam object.  (Thanks to Andy Joseph for the idea.)

   DOWNLOAD:  PyPAM-0.5.0.tar.gz

NEWS CONTENTS

• 20200724 : An introduction to Pluggable Authentication Modules (PAM) in Linux - Enable Sysadmin by Susan Lauber ( Jul 22, 2020 , www.redhat.com )
• 20080303 : Improve security with polyinstantiation. Using a Pluggable Authentication Module to protect private data by Robb R. Romans ( Feb 26, 2008 , developerworks )
• 20071210 : solaris-friendly pam_cracklib ( solaris-friendly pam_cracklib, Dec 10, 2007 )
• 20071204 : freshmeat.net Project details for pam_require ( freshmeat.net Project details for pam_require, Dec 4, 2007 )
• 20071201 : freshmeat.net Project details for pam_script ( freshmeat.net Project details for pam_script, Dec 1, 2007 )
• 20071125 : Linux-PAM 0.99.9.0 released ( Linux-PAM 0.99.9.0 released, Nov 25, 2007 )
• 20071125 : Re Pam-list Digest, Vol 41, Issue 6 ( Re Pam-list Digest, Vol 41, Issue 6, )
• 20071125 : Re Checking if PAM is used by login ( Re Checking if PAM is used by login, )
• 20071125 : Re Pam-list Digest, Vol 38, Issue 4 ( Re Pam-list Digest, Vol 38, Issue 4, )
• 20071125 : PAM in Open Solaris ( )
• 20061110 : Pluggable Authentication Module at OpenSolaris.org ( Pluggable Authentication Module at OpenSolaris.org, Nov 10, 2006 )
• 20061110 : OpenSolaris PAM repository by Darren Moffat ( OpenSolaris PAM repository , Nov 10, 2006 )
• 20061110 : OpenSolaris Forums/pam_securetty module for OpenSolaris ... ( OpenSolaris Forums/pam_securetty module for OpenSolaris ..., )
• 20061110 : Project details for pam_require ( freshmeat.net )
• 20061110 : LinuxDevCenter.com Secure Cooking with Linux, Part 3 ( LinuxDevCenter.com Secure Cooking with Linux, Part 3 , )
• 20061110 : Solaris 9 Operating Environment - Features and Benefits Security ( Solaris 9 Operating Environment - Features and Benefits Security, )
• 20061110 : Re solaris pam vs. padl.org pam for ldap ( Re solaris pam vs. padl.org pam for ldap, )
• 20061110 : Instructions for using LDAP server for login authentication using PAM ( Instructions for using LDAP server for login authentication using PAM, )
• 20061110 : Instructions for doing authentication with LDAP ( Instructions for doing authentication with LDAP, )
• 20061110 : Instructions for enabling TLS/SSL for LDAP server ( Instructions for enabling TLS/SSL for LDAP server, )
• 20061110 : My notes on installing Openldap on the Solaris 9 server ( My notes on installing Openldap on the Solaris 9 server, )
• 20061110 : Neohapsis Archives - PAM list - Solaris Pam + Kerberos + OpenSSH - From [email protected] ( Neohapsis Archives - PAM list - Solaris Pam + Kerberos + OpenSSH - From [email protected], )
• 20061110 : NETSYS.COM - The Intelligent Hackers Choice! PAM LDAP Archives ( NETSYS.COM - The Intelligent Hacker's Choice! PAM LDAP Archives, )
• 20061110 : redhat.com pam-list - Re (mod_auth_)pam crashes solaris 8 server ( redhat.com pam-list - Re (mod_auth_)pam crashes solaris 8 server, )

Old News ;-)

[Jul 24, 2020] An introduction to Pluggable Authentication Modules (PAM) in Linux - Enable Sysadmin by Susan Lauber

Jul 22, 2020 | www.redhat.com

Pluggable Authentication Modules (PAM) have been around since 1997. I was taught that PAM originated from Sun's Solaris, and it does appear that the first enterprise use and popularization occurred there. However, according to a 1997 article I found, the first full implementation was the Linux-PAM deployment. The article is still available from Linux Journal . The basic premise and implementation have not changed since then. There are some new keywords and many new modules, but overall the process is the same as 20 years ago.

More Linux resources

• Download Now: Linux Commands Cheat Sheet
• Advanced Linux Commands Cheat Sheet for Developers
• Download Red Hat Enterprise Linux Server 8 Trial
• Linux System Administration Skills Assessment

As the A in PAM indicates, PAM is about authentication. In most cases, when you log in to a system via a console or from across the network with SSH or Cockpit , PAM is involved. It doesn't matter if the user accounts are held locally or in a centralized location. For as much as it is used, it not common to manipulate the PAM configuration files directly. Other utilities do it for you. Many changes are made at installation, such as when installing the sssd RPM or using the ipa-client-install utility. The most common additional configurations can be handled by authconfig (RHEL7 and older) or authselect (RHEL8), or even through the Cockpit web interface. Most administrators do not learn about PAM configuration files until they get involved in advanced authentication and security topics.

What do we gain with PAM?

PAM separates the standard and specialized tasks of authentication from applications. Programs such as login , gdm , sshd , ftpd , and many more all want to know that a user is who they say they are, yet there are many ways to do that. A user can provide a user name and password credential which can be stored locally or remotely with LDAP or Kerberos. A user can also provide a fingerprint or a certificate as a credential. It would be painful to ask each application developer to rewrite the authentication checks for each new method. A call to PAM libraries leaves the checks to authentication experts. PAM is pluggable in that we can have different applications run different tests and modular in that we can add new methods with new libraries.

Let's look at the high-level steps taken when a locally-defined user logs into a text-based console:

• The login application prompts for a user name and password, then makes a libpam authentication call to ask, "Is this user who they say they are?" The pam_unix module is responsible for checking the local account authentication. Other modules may also be checked, and ultimately the result is passed back to the login process.
• The login process next asks, "Is this user allowed to connect?", then makes an account call to libpam . The pam_unix module checks for things like whether the password has expired. Other modules might check host or time-based access control lists. An overall response is handed back to the process.
• If the password has expired, the application responds. Some applications simply fail to log in the user. The login process prompts the user for a new password.
• To get the password verified and written to the correct location, the login process makes a password call to libpam . The pam_unix module writes to the local shadow file. Other modules may also be called to verify the password strength.
• If the login process is continuing at this point, it is ready to create the session. A session call to libpam results in the pam_unix module writing a login timestamp to the wtmp file. Other modules enable X11 authentication or SELinux user contexts.
• On logout, when the session is closed, another session call can be made to libpam . This is when the pam_unix module writes the logout timestamp to the wtmp file.

There are many components to PAM

If you make a change to authentication using a program such as authconfig or authselect and want to see what changed, here are some of the places to look:

/usr/lib64/security
A collection of PAM libraries that perform various checks. Most of these modules have man pages to explain the use case and options available.

/etc/pam.d
A collection of configuration files for applications that call libpam . These files define which modules are checked, with what options, in which order, and how to handle the result. These files may be added to the system when an application is installed and are frequently edited by other utilities.

Since there are several checks done by all applications, these files may also have include statements to call other configuration files in this directory. Most shared modules are found in the system-auth file for local authentication and the password-auth file for applications listening for remote connections.

/etc/security
A collection of additional configuration files for specific modules. Some modules, such as pam_access and pam_time , allow additional granularity for checks. When an application configuration file calls these modules, the checks are completed using the additional information from its corresponding supplemental configuration files. Other modules, like pam_pwquality , make it easier for other utilities to modify the configuration by placing all the options in a separate file instead of on the module line in the application configuration file.

/var/log/secure
Most security and authentication errors are reported to this log file. Permissions are configured on this file to restrict access.

man pam
This man page describes the overall process, including the types of calls and a list of files involved.

man pam.conf
This man page describes the overall format and defines keywords and fields for the pam.d configuration files.

man -k pam_
This search of man pages lists pages available for modules installed.

Wrap up

PAM allows for a much more robust authentication environment than per-application services could provide. It has been in Linux for many, many years, and is involved with nearly all user identification processes.

In the next article, I will walk through the format of the /etc/pam.d configuration files.

[Mar 3, 2008] Improve security with polyinstantiation. Using a Pluggable Authentication Module to protect private data by Robb R. Romans

Looks like Red Hat specific but probably can be adapted to other distributions.

Feb 26, 2008 | developerworks

If you're concerned about protecting world-writeable shared directories such as /tmp or /var/tmp from abuse, a Linux® Pluggable Authentication Module (PAM) can help you. The pam_namespace module creates a separate namespace for users on your system when they login. This separation is enforced by the Linux operating system so that users are protected from several types of security attacks. This article for Linux system administrators lays out the steps to enable namespaces with PAM.

To improve security, it's often wise to use more than one method of protection (also called "defense in depth"). That way, if one method is breached, another method remains operational and prevents further intrusion. This article describes a way to add another layer of depth to your security strategy: using PAM to polyinstantiate world-writeable shared directories. This means that a new instance of a directory, such as /tmp, is created for each user.

Polyinstantiation of world-writeable directories prevents the following types of attacks, as Russell Coker illustrates in "Polyinstantiation of directories in an SELinux system" (see Resources):

• Race-condition attacks with symbolic links
• Exposing a file name considered secret information or useful to an attacker
• Attacks by one user on another user
• Attacks by a user on a daemon
• Attacks by a non-root daemon on a user

However, polyinstantiation does NOT prevent these types of attacks:

• Attacks by a root daemon on a user
• Attacks by root (account or escalated privilege) on any user

How PAM and polyinstantiation work

PAM creates a polyinstantiated private /tmp directory at login time within a system instance directory; this redirection is transparent to the user logging in. The user sees a standard /tmp directory and can read and write to it normally. That user cannot see any other user's (including root's) /tmp space or the actual /tmp file system.

Polyinstantiated user directories are neither hidden nor protected from the root user. If you are interested in that level of protection, SELinux can help. The configuration examples provided here should work whether or not you have enabled SELinux. See Resources for links to more information about using SELinux.

Enabling polyinstantiation

This section shows you how to enable polyinstantiation of /tmp and /var/tmp directories for users on your system. It also describes the optional configuration steps necessary to accommodate X Windows or a graphical display manager. I used Red Hat Enterprise Linux 5.1 (RHEL 5.1) to write this article, but you can try the procedures described here on any Linux distribution that includes the pam_namespace module.

First we'll edit namespace.conf.

Edit namespace.conf

The first file you'll edit is /etc/security/namespace.conf, which controls the pam_namespace module. In this file, list the directories that you want PAM to polyinstantiate on login. Some example directories are listed in the file included with PAM and are commented out. Type man namespace.conf to view a comprehensive manual page. The syntax for each line in this file is polydir instance_prefix method list_of_uids.

[Dec 10, 2007] solaris-friendly pam_cracklib

solaris-friendly pam_cracklib is a reimplementation of pam_cracklib that builds and runs on Solaris as well as Linux. It is a PAM module for checking passwords with cracklib.

[Dec 4, 2007] freshmeat.net Project details for pam_require

pam_require is a simple Plugable Authentication Module (PAM) for Linux (and maybe other systems which use PAM). It is an account module that allows you to require a special group or user to access a service.

[Dec 1, 2007] freshmeat.net Project details for pam_script

pam_script is a PAM that executes a script at the start and end of a session. Any PAM-aware application can use the module to perform arbitrary operations. It was originally written for cleaning up when a user logs out.

Author:
Izak Burger [contact developer]

[Nov 25, 2007] Linux-PAM 0.99.9.0 released, Thorsten Kukuk

The Linux-PAM developement team is pleased to announce the release
of version 0.99.9.0

This is a bug fix release:

- misc_conv no longer blocks SIGINT; applications that don't want
user-interruptable prompts should block SIGINT themselves
- Merge fixes from Debian
- Fix parser for pam_group and pam_time

If you use pam_group or pam_time for your configurations, you
should update.

Please report bugs to the sourceforge bug tracking system.

Your Linux-PAM development team
--
Thorsten Kukuk, Project Manager/Release Manager SLES
SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg
GF: Markus Rex, HRB 16746 (AG Nuernberg)

Re Pam-list Digest, Vol 41, Issue 6

• From: Andreas Schindler <schindler az1 de>
• To: pam-list redhat com
• Subject: Re: Pam-list Digest, Vol 41, Issue 6
• Date: Wed, 11 Jul 2007 08:26:08 +0200

> Here are my other pam files,
>
>
> /etc/pam.d/common-auth:
>
> auth required pam_mount.so
> auth sufficient pam_winbind.so use_first_pass
> auth required pam_unix.so nullok_secure use_first_pass
>
>
> /etc/pam.d/common-pammount:
>
> auth       optional   pam_mount.so use_first_pass
> session    optional   pam_mount.so use_first_pass
>
>
> /etc/pam.d/common-session:
>
> session required        pam_unix.so
> session required        pam_mkhomedir.so umask=0022 skel=/etc/skel
> session optional        pam_mount.so
>
>
> Can someone please tell me what is going wrong?
>
>    Juan
>
>   
Juan,

IMHO pam_mount under section 'auth' doesn't make sense. Mounting devices
is a property of the session. What should pam_mount authenticate against? 

Please try and remove the 'auth' entries of pam_mount and try again.

Regards
Andreas

-- 
Dr.-Ing. Andreas Schindler
 
Alpha Zero One Computersysteme GmbH
Frankfurter Str. 141
63303 Dreieich
 
Telefon 06103-57187-21
Telefax 06103-373245
 
schindler az1 de
www.az1.de

Alpha Zero One Computersysteme GmbH, Brandeniusstr. 3, 44265 Dortmund
HRB 11089 Amtsgericht Dortmund, Geschäftsführer : Klaus-Jürgen Koke, Joachim Carle 

RE Pam-list Digest, Vol 41, Issue 6

• From: "Whittier, Kevin CTR 63134" <kevin whittier ctr navy mil>
• To: "Pluggable Authentication Modules" <pam-list redhat com>
• Subject: RE: Pam-list Digest, Vol 41, Issue 6
• Date: Wed, 11 Jul 2007 07:42:37 -0700

Juan,
In the auth section you need to authenticate the user first and if that succeeds then mount their directory. Try this:

auth sufficient pam_winbind.so
auth required pam_unix.so nullok_secure use_first_pass
auth optional pam_mount.so use_first_pass

When the user is authenticated either by pam_winbind or pam_unix (note the re-use of the password), then the pam_mount can also re-use the password (The password is only required if the file system is encrypted) to optionally mount the directory. If pam_mount fails for some reason the login will still succeed.


Kevin Whittier (CISSP)
Senior Linux Architect
Fleet Numerical Meteorology and Oceanography Center (FNMOC)
831 656-4603
Kevin whittier ctr navy mil 

Re Checking if PAM is used by login

• From: "Kenneth Geisshirt" <kenneth geisshirt dk>
• To: "Pluggable Authentication Modules" <pam-list redhat com>
• Subject: Re: Checking if PAM is used by login
• Date: Tue, 26 Jun 2007 11:13:39 +0200 (CEST)

On Tue, June 26, 2007 10:14, David Resnick wrote:

> Is there any method of checking if the services are compiled to use the
> PAM modules?

First of all, all Linux distributions (to my knowledge Slackware is the
only exception) use PAM for authentication (login) and password changes.

Second, you should take a look at /var/log/message (or similar) where PAM
is write log messages. For example I have the following in my log:

Jun 26 11:10:01 colws01m crond(pam_unix)[5283]: session opened for user
root by (uid=0)
Jun 26 11:10:01 colws01m crond(pam_unix)[5283]: session closed for user root

/kneth

Re Pam-list Digest, Vol 38, Issue 4

• From: Andreas Schindler <schindler az1 de>
• To: pam-list redhat com
• Subject: Re: Pam-list Digest, Vol 38, Issue 4
• Date: Thu, 12 Apr 2007 08:24:00 +0200

pam-list-request redhat com wrote:

Send Pam-list mailing list submissions to

Re: [Pam-patches] New pam items
From:

I can't figure out, what PAM_DEVICE should be good for. IMHO it is far
too unspecific to be really useful.

To the discussion about PAM_DISPLAY: Before all, please consider that every X-Display on a local machine (i.e. DISPLAY=x.x or localhost:x.x)

ALWAYS has an associatet TTY, because the X-Server needs a (pseudo-)device
to attach to. So, PAM_TTY and PAM_DISPLAY should be independent of each other.

By the way: why not use the PAM environment to store additional information?
Annother way could is possible using pam_set/get_data.
I've done this successfully when implementing a TACACS-to -PAM gateway.
In conjunction with a special PAM module to store and retrieve Information
i consider this a very smooth way to associate additional information with PAM.

Your's
Andreas

Dr.-Ing. Andreas Schindler

PAM in Open Solaris

RBAC - Role Based Access Control at OpenSolaris.org

OpenSolaris UserGroup RBAC presentation

RBAC Best Practices for OpenSolaris developers

The following best practice documents for using RBAC in developing other parts of OpenSolaris can be found in the ARC community:

• When to use setuid vs RBAC roles

• Adding New authorisations to OpenSolaris

• Bulding RBAC Rights Profiles

Why use

PAM were created by Sun and first appeared as a public interface in Solaris 2.6. Previous versions of a very similar framework were in Solaris 2.4 and Solaris 2.5.1. Until Solaris 9 there was only one module, pam_unix.so, that implemented the default UNIX username/password policy. In Solaris 9 we broke up that module in to a number of smaller parts: pam_unix_auth.so, pam_unix_cred.so, pam_authtok_get.so, pam_authtok_check.so, pam_authtok_store.so, pam_dhkeys.so and pam_passwd_auth.so.

Sample Modules

---

In the files section there are a few sample modules and programs that I (Darren Moffat) have had lying around in my home directory at Sun since I first started playing with PAM before Solaris 2.6 was released.

• pam_xauth_cred.so

I originally called this su_cookie.so, and it was one of my earliest PAM modules. I'm not proud of the way it is coded and it is an ugly hack since it uses the xauth(1) program to do its work. However I've always found it very useful, no more xhost + for me :-) I know that some Linux based distros ship with something like this but I'm pretty confident I was the first to implement it and someone else idependently came up with the idea.

• pam_app_auth

This is a simple demo application that calls the PAM APIs that an application would call. I use it as a very simple test application, not really useful for anything else.

• pam_root_console.so

This is a PAM implementation of the check that /bin/login has hardcoded for root on the system console.

• pam_netgroup.so

Basically this is a local file that contains usernames and/or netgroups that should either be allowed or denied access to a given service. The idea for this module came from observing the performance hit that the nsswitch passwd_compat +/- syntax can have on some systems. What most people used that for was invalidating the users shell and/or password so they couldn't login, but still allow the admin to get uid->name translations of the files the users owned on the server. This module has appeared in SunSolve articles in the past. I wrote this version of it in 1999.

[Nov 10, 2006] Pluggable Authentication Module at OpenSolaris.org

PAM were created by Sun and first appeared as a public interface in Solaris 2.6. Previous versions of a very similar framework were in Solaris 2.4 and Solaris 2.5.1. Until Solaris 9 there was only one module, pam_unix.so, that implemented the default UNIX username/password policy. In Solaris 9 we broke up that module in to a number of smaller parts: pam_unix_auth.so, pam_unix_cred.so, pam_authtok_get.so, pam_authtok_check.so, pam_authtok_store.so, pam_dhkeys.so and pam_passwd_auth.so.

Sample Modules

---

In the files section there are a few sample modules and programs that I (Darren Moffat) have had lying around in my home directory at Sun since I first started playing with PAM before Solaris 2.6 was released.

• pam_xauth_cred.so

I originally called this su_cookie.so, and it was one of my earliest PAM modules. I'm not proud of the way it is coded and it is an ugly hack since it uses the xauth(1) program to do its work. However I've always found it very useful, no more xhost + for me :-) I know that some Linux based distros ship with something like this but I'm pretty confident I was the first to implement it and someone else idependently came up with the idea.

• pam_app_auth

This is a simple demo application that calls the PAM APIs that an application would call. I use it as a very simple test application, not really useful for anything else.

• pam_root_console.so

This is a PAM implementation of the check that /bin/login has hardcoded for root on the system console.

• pam_netgroup.so

Basically this is a local file that contains usernames and/or netgroups that should either be allowed or denied access to a given service. The idea for this module came from observing the performance hit that the nsswitch passwd_compat +/- syntax can have on some systems. What most people used that for was invalidating the users shell and/or password so they couldn't login, but still allow the admin to get uid->name translations of the files the users owned on the server. This module has appeared in SunSolve articles in the past. I wrote this version of it in 1999.

[Nov 10, 2006] OpenSolaris PAM repository by Darren Moffat

I've just setup the start of a PAM page on OpenSolaris.org as part of the OpenSolaris security community.

http://opensolaris.org/os/community/security/projects/pam/

I started with some of the PAM modules that I've had sitting in my home directory. I was interesting, for me, to see that I wrote some of these about 9 years ago. I've released these under the CDDL.

If other community members have modules they would like to contribute then send me the code and a description and I'll put them up there.

Note that there is no commitment that these modules will appear in any future release of Solaris or any other OpenSolaris based distro, but there is also nothing stopping distro makers from doing so.

( Apr 27 2006, 03:37:37 PM BST ) Permalink

OpenSolaris Forums/pam_securetty module for OpenSolaris ...

Please review the attached proposal and help with the outstanding issues before I submit this as an ARC case.

Note that the Virtual Console project could end up depending on this case but does not at this time.

--
Darren J Moffat
Background
----------
In a default Solaris install root is restricted to being able to login only on the /dev/console device.

This functionality can be disabled by commenting out the CONSOLE= variable in /etc/default/login. It can also be changed to give a different device name, however it supports only a single device.

Orthogonally to this root can be made a role and can not login directly at all.

This check is currently implemented in login(1) rather than in a PAM module where it really belongs.

On some Linux and BSD distributions there is PAM module called pam_securetty that implements the check. Even though the module name is the same the configuration file differs between distributions. On NetBSD for example the pam_securetty module looks at /etc/ttys for the secure flag listed against that tty. On CentOS/RedHat Linux
the pam_securetty module uses /etc/securetty which is a per line list of file names relative to /dev that are considered secure.

Problem Area
------------
When OpenSolaris gains Virtual Consoles (PSARC/2006/591) there may be multiple "local" devices that root could login on. Rather than overloading the string "/dev/console" to mean /dev/console and all of the virtual console devices this project proposes removing the check from login(1) and implementing it in a PAM module.

Solution
--------
This case proposes the introduction of a pam_securetty(5) module and the removal of the explicity check for CONSOLE= from login(1). The OpenSolaris pam_securetty will perform the CONSOLE= check, so that that interface is preserved. In additon to the CONSOLE= check the module will also check a file named /etc/securetty, if this had been a pure OpenSolaris creation it would probably have been named /etc/security/tty or similar but there seems to be no valid reason
to invent another pathname.

The format of the file will be one device name (relative from /dev) per line, blank lines and those beginning with # are ignored all other lines are assumed to be the name of a device. Paths containing /../ are not allowed and will be skipped.

Since the check is being removed from login(1) the new module needs to be in the PAM account stack for all services that currently use login(1). On upgrade i.pamconf will add the following entry to /etc/pam.conf

other account required pam_securetty.so.1

If i.pamconf finds any additional account stacks other than the one for cron it will log a message to the upgrade log to tell the administrator that they need to verify their pam.conf file is correct.

Source
------
Due to the need to add the additional CONSOLE= check by reading /etc/default/login this module will be implemented from scratch for Solaris rather than using one from LinuxPAM or from a BSD distribution.

Outstanding issues
------------------
Is there any impact to Zones ?
Is there any overlap impact with TX ?

TODO
----
New man page for pam_securetty(5)
Updated man page login(1)
_______________________________________________
vconsole-discuss mailing list
vconsole-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/vconsole-discuss

Project details for pam_require

freshmeat.net

Added: Thu, Feb 27th 2003 13:20 PDT (1 year, 6 months ago)
Updated: Thu, Sep 23rd 2004 00:26 PDT (today)
About: pam_require is a simple Plugable Authentication Module (PAM) for Linux (and maybe other systems which use PAM). It is an account module that allows you to require a special group or user to access a service.

Release focus: Minor bugfixes

Changes: A missing check for primary group membership was added.

Author: Andreas Gohr [contact developer]

LinuxDevCenter.com Secure Cooking with Linux, Part 3

Author's note: PAM (Pluggable Authentication Modules) is a flexible infrastructure for controlling authentication on Linux systems. In this recipe, taken from Chapter 4, "Authentication Techniques and Infrastructures," we show you how to restrict authentication to a given set of users by creating an access control list.

Problem. You would like to apply an access control list (ACL) to an existing service that does not explicitly support ACLs (e.g., telnetd, imapd, etc.).

Solution. Use the listfile PAM module.

First, make sure the server in question uses PAM for authentication, and find out which PAM service name it uses. This may be in the server documentation, or it may be clear from examining the server itself and perusing the contents of /etc/pam.d. For example, suppose you're dealing with the IMAP mail server. First notice that there is a file called /etc/pam.d/imap. Further, the result of:

# locate imapd
...
/usr/sbin/imapd

shows that the IMAP server is in /usr/sbin/imapd, and:

# ldd /usr/sbin/imapd
libpam.so.0 => /lib/libpam.so.0 (0x40027000)
...

shows that the server is dynamically linked against the PAM library (libpam.so), also suggesting that it uses PAM. In fact, the Red Hat 8.0 IMAP server uses PAM via that service name and control file ("imap").

Continuing with this example, create an ACL file for the IMAP service, let's say /etc/imapd.acl, and make sure it is not world-writable:

# chmod o-w /etc/imapd.acl

Edit this file, and place in it the usernames of those accounts authorized to use the IMAP server, one name per line. Then, add the following to /etc/pam.d/imap:

account required /lib/security/pam_listfile.so file=/etc/imapd.acl \
item=user sense=allow onerr=fail

With this configuration, only those users listed in the ACL file will be allowed access to the IMAP service. If the ACL file is missing, PAM will deny access for all accounts.

Solaris 9 Operating Environment - Features and Benefits Security

The PAM framework has been changed to consist of more modular, smaller shared object files. The PAM API has not been changed. Isolation from naming services is greater.

Specifically, the framework has been enhanced to allow customers to concentrate on developing their own solution without needing to manipulate many of the naming service and authentication details.

Re solaris pam vs. padl.org pam for ldap

Our first goal was to install the operating systems and then install openldap to fiddle around and understand how it works. Installing the Solaris OS proved to be quite a challenge in itself as none of us had prior experience working with it. Thus we decided to do a parallel installation and configuration on the Linux platform as well. Much of the documentation on the Internet was done on the Linux platform, thus we can get a comparison between the Solaris and Linux installation and configurations.

On the Linux platform, I used the default RedHat 7.3 distribution with all packages added and then patched them with the up2date program provided by RedHat.The package versions for the main components are as follows:

openssl096-0.9.6-6
db3-3.3.11-6
cyrus-sasl-1.5.24-25
krb5-libs-1.2.4-1
krb5-server-1.2.4-1
openldap12-1.2.13-3

Instructions for using LDAP server for login authentication using PAM

The references I used to configure the setup can be found here:
Instructions for doing authentication with LDAP
Exploring LDAP -- Part I (Basics), Part II (Directories), Part III (Advanced Topics)

Note: It seems that with RedHat 7.0 onwards you can use authconfig to change the system settings to use LDAP for authentication as well as user information.

Next, we did a check using a network sniffer(Ethereal) and discovered that the passwords were being sent in plain text.(!!!) Thus it was imperative to protect the passwords using some form of encryption. The easiest way to do so seemed to be to protect the transport of the passwords or data with an SSL layer. Fortunately OpenLDAP v2 has built in support for TLS/SSL.

Instructions for enabling TLS/SSL for LDAP server

Upon further testing, we found that Solaris 9 had some problems changing the LDAP passwords on the Linux RH7.3 server with TLS enabled. It works fine the other way. We installed the latest version of Openldap(2.1.3) onto another Solaris 9 server and it works fine there. Solaris 9 now comes with its own version of OpenSSL and LDAP libraries which are TLS enabled.

My notes on installing Openldap on the Solaris 9 server

'I forgot my password!'
When using the PAM to change passwords for LDAP users, it is necessary to have the users' old password. In the event that the user has lost his old password, you will have to modify the LDAP directory directly. Openldap provides a method of doing this with a command called: ldappassword. In general, to change a user's userPassword field in LDAP, use the command shown below. If you omit the -S option, a random password will be generated.

/usr/local/bin/ldappasswd -h yourldaphost.test.org -D "cn=yourrootDN,dc=test,dc=org" -w rootDNpasswd -S \
"uid=youruserid,ou=people,dc=test,dc=org"
             

"A line segment that joins the center of a circle with any point on its circumference"
With LDAP up and running, we proceeded to the next part of the project which was to implement a RADIUS server which would connect back to the LDAP backend and use usernames and passwords from the central database. Looking around, we found FreeRadius, which the name implies is free, and supports LDAP as well.

Once configured, we tested the RADIUS server using a Cisco 3500 switch. The Radius protocol provides encryption of the password before sending it onto the network. However we still have to provide encryption between the Radius server and the LDAP server.

Instructions for setting up and configuring FreeRadius Server on Linux

We tested GNU Radius with PAM on Solaris 9 as well. Details can be found here.(courtesy of HoMY)

One calorie breath mint - TicTACACS
The next part of the project was to include TACACS+ to the list of authenticating services available. This was quite straightforward. We obtained the package and followed the instructions found on this site: LDAP support for Tacacs+
It is also possible to get the TACACS+ server to run with PAM. Instructions here:

[Mun Yew] Configure Tac_Plus to use PAM.

Lets do the SAMBA!
Initial attempts to configure Samba (2.2.5) with pam had some drawbacks. We could have either a centralised database in LDAP with the samba schema included BUT require passwd to change the unix password and smbpasswd to change the NT/LM passwords separately, OR let samba have its own database for storing the NT/LM passwords and configure PAM to change both passwords using only passwd. With the latest CVS of Samba (2.2.6pre2), it solved most of the bugs and enabled us to have a unified respository for the passwords and a single method of changing them. Some patches are required to get TLS working in Solaris 9 though. Hopefully it would be included in future releases of Samba.

Instructions on installing and configuring a samba-PDC linked to LDAP backend

No queues for qmail
qmail was the chosen MTA to be used and integrated to use the LDAP username and passwords. Installation of the qmail server was quite straightforward with many websites providing installation and configuration instructions. A checkpassword module which was PAM aware is required.
Details of our installation can be found here. (courtesy of Pat)

A PAtCHy sErver
Apache 2.0.41 and above comes with mod_ldap and mod_auth_ldap modules(currently experimental). However it does require the OpenLDAP SDK (both 1.x and 2.x) or the iPlanet (Netscape) SDK.

Instructions on installing and configuring a Apache 2 with mod_auth_ldap

Links :

PAM
Introduction to PAM
Solaris-PAM
Linux-PAM

LDAP
OpenLDAP.org
Introduction to LDAP
LDAP Implementation HOWTO
Solaris OpenLDAP
NIS+ to LDAP Migration in the SolarisTM 9 Operating Environment [pdf]
[HoMY] Steps to configure OpenLDAP to work
[HoMY] Steps to provide Authentication Services for OpenLDAP

RADIUS
Freeradius.org
LDAP Implementation HOWTO

TACACS+
LDAP support for Tacacs+
Single-User Network Access Security TACACS+ (by CISCO)
TACACS+ and RADIUS Comparison (by CISCO)

OpenSSL
OpenSSL.org

Berkeley Database
Sleepycat Software
[Mun Yew] Berkeley Database 4.0.14 Installation notes

SAMBA
Samba.org
SAMBA (v 2.2) PDC LDAP v.3 howto

QMAIL
qmail.org
Life with qmail

APACHE
Apache.org
mod_ldap
mod_auth_ldap

Neohapsis Archives - PAM list - Solaris Pam + Kerberos + OpenSSH - From [email protected]

NETSYS.COM - The Intelligent Hacker's Choice! PAM LDAP Archives

redhat.com pam-list - Re (mod_auth_)pam crashes solaris 8 server

Recommended Links

Softpanorama Recommended

Top articles

Sites

Sun blueprints

• Extending Authentication in the Solaris 9 Operating Environment Using Pluggable Authentication Modules (PAM): Part I (September 2002)
  -Michael Haines
  This article is the first of a two-part series that offers a technical overview of how the Solaris 9 Operating Environment implementation of Pluggable Authentication Modules (PAM) works. This article demonstrates straightforward methods for configuring PAM to accommodate site-specific security policy requirements and examines the PAM architecture and its components.

• Extending Authentication in the Solaris 9 Operating Environment Using Pluggable Authentication Modules (PAM): Part II (October 2002)
  -by Michael Haines and Joep Vesseur
  This article is part two of a two-part series and details the PAM application programming interface (API) and the PAM service provider interface (SPI). Also included are procedures on how to effectively write PAM modules when using the Solaris 9 Operating Environment (Solaris 9 OE). By writing these PAM service modules, it is possible to extend the capability of the Solaris 9 OE authentication mechanisms in a number of different ways.

  Part one, Extending Authentication in the Solaris 9 Operating Environment Using Pluggable Authentication Modules (PAM): Part I, was published in the September 2002 issue of Sun BluePrints Online.

PAM information and experiences some Solaris information

UW-ID-AUTH Solaris PAM Authentication

The UWdir Identification and Authentication service can be used to provide authentication services to PAM aware applications on the Solaris/Unix platform. This note describes how to obtain and configure an xhier package which will allow Solaris systems to authenticate against the Uwaterloo.ca NT4 Domain. A basic configuration allows all PAM aware applications to use the UW/ID-AUTH service; site specific configurations are possible.

Discussion

PAM (the Pluggable Authentication Module) is a service found in current versions of Solaris (2.6 and later) ager to customize the authentication services that should be used for various applications. The applications (typically login, ftp, dtlogin and other programs that "log a user in") are built to be aware of the services PAM offers -- ie. the program knows how to get PAM to do the authentication. To take advantage of UW/ID-AUTH Solaris PAM Authentication you're going to need:

• Credentials in the Uwaterloo.ca domain -- ie. a UWdir userid and password.
• how to do authentication in the Uwaterloo.ca domain.
• A PAM configuration that instructs applications to use that method.

All PAM implementations rely on the notion of "dynamic linking". The PAM aware application loads the appropriate shared libraries required to do authentication at run time -- it links itself dynamically as required. The PAM library itself is a shared library and it knows how to bring in other shared libraries. The important manual pages to see are pam(3) and pam.conf(4) which describes the configuration file. The configuration file /etc/pam.conf lets the system manager customize the authentication sequence by specifying shared libaries that should be used and how they should be ordered.

http://www.us.kernel.org/pub/linux/libs/pam/

• RFC 86

• The Linux-PAM System Administrators' Guide -- Andrew G. Morgan, [email protected] DRAFT v0.71 1999/11/8

• The Linux-PAM Module Writers' Guide -- Andrew G. Morgan, [email protected] DRAFT v0.71 1999/11/8

• The Linux-PAM Application Developers' Guide

• docs.sun.com System Administration Guide, Volume II -- PAM were invented by SUN

  • Introduction to PAM

  • Overview of PAM

  • PAM Functionality

  • Configuring PAM

  • How to Add a PAM Module

  • How to Initiate PAM Error Reporting

  • Linux PAM under Solaris

• A Linux-PAM page -- contains Linux PAM System Administrator Guide

  • Info on PAM modules and applications that reside around the 'net.
  • The beginnings of a FAQ
  • Online documentation
  • Offline documentation
  • FindMail have taken on the task of archiving the Linux-PAM mailing list. If you want to subscribe to the mailing list, try emailing [email protected].
  • Here is a working document attempting to generalize PAM to support client<->server programming models. The original DCE/OSF-RFC as proposed by the people at SunSoft.
  • Further documentation courteously made available by Sun Microsystems,
    • The manual for pam.conf
    • The manual for pam
    • The manual for pam_sm module functions
    • The manual for pam_get_user
    • The XSSO spec which is X/Open's attempt to absorb PAM into something bigger (draft from 1997 courteously made available to us by Vipin).
  • Some more information for you if you want to use both Solaris and Linux's PAM implementation.
  • Linux-PAM modules etc. page

• TUCOWS NETWORK:What the Heck is PAM anyhow? By Kevin Fenzi ([email protected])

• PAM - pluggable authentication modules in Red Hat Linux -- very important security tool; a must.

• User Authentication with PAM (Red Hat info)

• pam-0.68-12.i386 RPM (Suse Info)

• Squid PAM authenticator module

• The Answer Guy 29 TACACS and RADIUS Authentication Models for Linux and-or PAM

• Beginner's guide to armoring Linux

• Linux Security Audit Project Archive June 1998 Re Secure-linux and standard kernel

Papers

Enterprise Linux Magazine

Pluggable authentication modules (PAM) were originally developed by Sun Microsystems and released as an undocumented feature in Solaris 2.3. Since then, Sun has done little with PAM, compared to the open source community, and most specifically, the Linux community. In this article, we will explore the general role of Linux-PAM, its components, configuration and a few general examples of its use.

The Purpose of PAM

The principal purpose of PAM is to provide a framework for authenticating users on a system. To put PAM in perspective, consider the very commonly implemented programs ftp and telnet. Historically, each of these utilities incorporated its own authentication mechanism through its associated daemon: telnetd and ftpd, respectively. Telnetd would use the authentication algorithm supplied by the login program while the ftpd incorporated its own authentication algorithm. These algorithms are quite similar and in most UNIX implementations, ultimately resolved to the use of the entries found in /etc/passwd (and, in some cases, /etc/shadow or similar files). Figure 1 depicts the authentication procedure in this case.

TUCOWS NETWORKWhat the Heck is PAM anyhow? By Kevin Fenzi ([email protected])

Some of your might have noticed mention of PAM in security circles. In this article I will describe how PAM works and demonstrate it's usefulness.

PAM stands for Pluggable Authentication Modules. Basically PAM is a way to change on the fly the way applications or services are authenticated. When you use PAM, you can define at run time how an application or service is authenticated, rather than having to recompile it.

To see why PAM is so usefull, first a bit of UNIX history. Authentication of users was first done using a flat, world readable /etc/passwd file. This file would contain the encrypted password for the user, along with some other information. When a application or service needed to authenticate a user, they would query the user for their password, encrypt it and compare it to the entry in the /etc/passwd file. This worked surprisingly well for a number of years.

Since the /etc/passwd file was readable to everyone (so they could use it to do things like map uids to names and so forth), this meant that encrypted passwords could be examined by others and brute force password crackers could be employed against them. If the user choose a "good" password the cracker would not get anything, but in a large /etc/passwd file, there was always bound to be someone who selected their login name as a password, or "dog" or any easily guessed passwords for the cracker. The first brute force password crackers were simply scripts that would take each word in the dictionary, encrypt them, and test them against each users password entry. Modern ones have gotten a lot more elaborate (checking dictionary names backwards, with numbers and punctuation and the like).

To combat this attack, "shadow" passwords were invented. While most of the user specific information would continue to exist in the /etc/passwd file, the encrypted password and other sensitive data would be moved to an /etc/shadow file that would only be readable by the root user. This made it much harder for crackers to gain access to the encrypted passwords. However, it also meant that all applications that were expecting to authenticate someone had to be modified and re-compiled to look for the password in the /etc/shadow file and not in the /etc/passwd file. By the time this change was starting to gain a lot of acceptance, there were hundreds of applications out there that had to be modified.

A number of systems had also been developed to handle large numbers of users. Typical /etc/passwd files were fine for a few hundred or a few thousand people, but larger unix sites were coming on-line. Replaceing /etc/passwd with a database to cut down lookup times was essential. This required more modification and recompiling of applications.

There are several other schemes for authenticating users that depend on yet other files and servers to communicate with. RADIUS authentication requires you to talk to a RADIUS server. Kerberos requires you to talk to a Kerberos server and so on. All the applications and services that want to authenticate with one of these other servers has to be modified and re-compiled to work with the server they are talking to. This requires modifying all those services and applications again and again.

Pluggable Authentication Modules (PAM) was designed to provide a generic method of accesing a variety of password and other authentication schemes. As the name implies, there is a set of modules which may be "plugged in" to change the behavior of authentication. Effectively, program simply asks PAM "Is this user allowed to access the service I'm offering", and PAM takes care of the background details of searching /etc/shadow, /etc/passwd, checking times, etc...

The "pluggable" means that as your authentication needs change, your software can be adjusted to fit without having to recompile (often a great number of) applications. You simply change the PAM configuration file to reflect the changes in your authentication.

Lets take a look at a PAM configuration file from redhat-6.0. Each service has it's own configuration file. So there is a PAM configuration file for ftp, login, imap, passwd, etc..

This is the /etc/pam.d/rlogin file:

#%PAM-1.0
auth       required     /lib/security/pam_securetty.so
auth       sufficient   /lib/security/pam_rhosts_auth.so
auth       required     /lib/security/pam_pwdb.so shadow nlok
auth      required     /lib/security/pam_nologin.so
account    required     /lib/security/pam_pwdb.so
password   required     /lib/security/pam_cracklib.so
password   required     /lib/security/pam_pwdb.so nullok use_authtok md5 shadow
session    required     /lib/security/pam_pwdb.so

The format of the files in /etc/pam.d/ is:

module-type control-flag module-path arguments

Modules are "stackable", meaning that all the modules are run thru in order. If the "control-flag" is "required" then if any one of them fails, the user is not authenticated.

So, this config for rlogin first runs the pam_securetty.so module. This checks to see if someone is logging in as root, and if so checks the /etc/securetty file to see if the terminal they are logging in on is "secure". If it's not, then they are rejected.

Next it would run the pam_rhosts_auth.so module. This module checks to see if the user has a ~/.rhosts file that would automaticly grant them access. If so, since it's control-flag is "sufficient", it can grant the user access by itself.

Next the pam_pwdb.so module is called. This is the regular password checking module. It's called with "shadow nullok" so it will also check /etc/shadow files, and if the user had a null password set, it will still allow them access.

Finally in the authentication type modules, pam_nologin.so is called. If you have a /etc/nologin file, it will show the user the contents of this file and disallow access.

Once a user has logged in, the "account" module(s) are used to record when users log in and out. In this case, the "pam_pwdb.so" module is used which writes the accounting information to syslog and updates /etc/utmp and /etc/wtmp.

The next two lines are for password changing. The first, pam_cracklib.so will check your potential new password against Crack rules to make sure the password you select is a good one. The second will update /etc/passwd and/or /etc/shadow.

Finally, the last line is a "session" type. This allow the pam_pwdb.so module to do anything that the user might need before their session (mounting directories, etc).

You can see that PAM is designed to allow all sorts of modules to authenticate the user to applications or services. Of course, for PAM to be totally useful, all those old programs and services would need to be converted to use PAM. Luckily, the vast majority already have been converted. There are even apache modules for interacting with PAM, as well as python bindings (PyPAM).

Using PAM, you can tailor your authentication to your needs. I would reccomend that you comment out (or remove) the pam_rhosts.so module in all your services files. .rhost files are woefully insecure in these days of spoofing IP addresses.

Another good PAM file to look over and possibly tweak would be the /etc/security/limits.conf. The /etc/security directory contains a number of control files that describe PAM's environment and operations. The limits.conf file shows limits that PAM should put on groups of users when they finish authentication. In this file you can limit the number of processes, amount of memory, and other reaources that users will have available. This is very useful in a public machine that might be subject to "fork bombs" or the like. You can even allow some groups more resources if you so choose.

RedHat 6.0 asks you at install time if you would like to enable MD5 passwords. If you say yes to this option, you will get the ability to have much longer passwords, and likely they will be more secure. Note though, that if you have some application that is shadow aware, but not PAM aware, it will no longer function. Since many applications out there got converted to shadow password files, but not all have been modified to support PAM, you need to be careful when selecting MD5 passwords.

For more information on PAM, see the PAM web page at:

Reference

PAM Essentials

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: July 26, 2020