PAM : Pluggable Authentication Modules

In this article we will explore PAM ,which is a research over the internet and found so many wonderful article related to this topic written by some great guys.Kindly look into resources section of this article(at the bottom) to find the article glue with it.I am just trying to reproduce the great work done by others in those article and after going through all of those to understand how it work underneath.It is a very very important tool for any open system administrators.And not to mention that a complex topic to master,but once grasp one can do hell lot of thing with this to make system infrastructure more effective and secure.

PAM (Pluggable Authentication Modules) is a suite of shared libraries that enable the local system administrator to choose how applications authenticate users.

The function of the configuration file(s) is to provide a mapping from the application’s service name to a selection of modules that provide authentication services to the raw application. When a pam aware application with a file in /etc/pam.d starts, the PAM library loads the configuration for the specified service and constructs four module chains (one for each facility.) If the configuration does not specify any modules for one or more facilities, the configuration for the other service is used instead for these facilities.

Linux as a server, can provide several different services (e.g., web, ftp with areas restricted by password control). Through the use of modules, PAM can enable a program to search through several different password databases, even if that program is not explicitly coded for that particular database.

Here are some examples of the possibilities that this enables.

  • Apache has a module that provides PAM services. Now authentication to use particular directories can be conducted by PAM, which means that the range of modules that are available to PAM can be used, including RADIUS, NIS, NCP (which means that Novell password databases can be used).
  • pppd has a PAMified version (available from RedHat) Now it is possible to use a series of databases to authenticate ppp users. In addition to the normal Linux-based password databases (such as /etc/passwd and /etc/shadow), you can use PAM modules to authenticate against Novell password databases or NT-based password databases.
  • The preceding two examples can be combined. Imagaine that the persons in your office or department are already registered with a username and password in a Novell or NT LAN. If you wanted to use this database on your Linux server (for PPP access, for web access, or even for normal shell access), you can use PAM to authenticate against this existing database, rather than maintain a separate database on both Linux and the LAN server.

PAM configuration files, located in /etc/pam.d and named for the service which they control have three fields, with optional fourth and greater fields. The first field in the configuration file is the module-type indicatiing which of four PAM management services the correspoding module will provide to the application. PAM deals with four separate types of management services. 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. The four types of management services are: authentication management; account management; session management; and password management.

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.

account

Determines whether the user is allowed to access the service. This is different from establishing whether the user is who they say they are. Account management deals with enforcing the expiration of passwords and preventing logins during system time.

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.

Control:

PAM modules can be stacked – there can be any number of modules of the same module type for a single application. The application is not told of the individual success or failure of any module, only of the success or failure of the stack. The control flags determine how each module affects the success or failure of the stack. Modules in the stack are executed in the order they are listed in the configuration file.

The second field in the configuration file is the control token, which tells PAM what should be done in if authentication by this module fails. PAM recognizes four control types: required, requisite, sufficient, and optional.

requisite
The module must succeed for the stack of this module type to succeed. Failure to authenticate via this module results in immediate denial of authentication.

required
The module must succeed for the stack of this module type to succeed. Failure also results in denial of authentication, although PAM will still call all the other modules listed for this service before denying authentication.

sufficient
Success of this module is sufficient for the stack of this module type to succeed. If authentication by this module is successful, PAM will grant authentication.

optional
Not critical to the success or failure of the stack. If at least one non-optional module succeeds or fails, the result of this module is ignored when calculating the success or failure of the stack. Whether this module succeeds or fails is only significant if it is the only module of its type for this service.

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. Since Linux-PAM-0.56 was released there is support for a default authentication-module directory, and a full path is no longer required, only the name of the module. PAM looks for the modules in the default PAM module directory, normally /usr/lib/security. However, if your linux distribution conforms to the Linux Filesystem standard, PAM modules can be found in /lib/security.

Module Arguments:

Any further fields contain any arguments 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”).

The following are a list of module options that are likely to be recognize by all modules:

  • debugUse the syslog(3) call to log debugging information to the system log files.
  • no_warn
  • Instruct module to not give warning messages to the application.
  • use_first_pass The module should not prompt the user for a password. Instead, it should obtain the previously typed password (from the preceding auth module), and use that. If that doesn’t work, then the user will not be authenticated. (This option is intended for auth and password modules only).
  • try_first_pass The module should attempt authentication with the previously typed password (from the preceding auth module). If that doesn’t work, then the user is prompted for a password. (This option is intended for auth modules only).
  • use_mapped_pass This argument is not currently supported by any of the modules in the Linux-PAM distribution because of possible consequences associated with U.S. encryption exporting restrictions. Within the U.S., module developers are, of course, free to implement it (as are developers in other countries). For compatibility reasons we describe its use as suggested in the DCE-RFC 86.0, see section bibliography for a pointer to this document.The use_mapped_pass argument instructs the module to take the clear text authentication token entered by a previous module (that requests such a token) and use it to generate an encryption/decryption key with which to safely store/retrieve the authentication token required for this module. In this way the user can enter a single authentication token and be quietly authenticated by a number of stacked modules. Obviously a convenient feature that necessarily requires some reliably strong encryption to make it secure. This argument is intended for the auth and password module types only.
  • expose_account In general the leakage of some information about user accounts is not a secure policy for modules to adopt. Sometimes information such as users names or home directories, or preferred shell, can be used to attack a user’s account. In some circumstances, however, this sort of information is not deemed a threat: displaying a user’s full name when asking them for a password in a secured environment could also be called being friendly. The expose_account argument is a standard module argument to encourage a module to be less discrete about account information as it is deemed appropriate by the local administrator.

Example configuration file entries

Let’s look at some examples of pam configuration files. The first example is for the other or default service. If there is not a specific pam configuration file in /etc/pam.d for a service, this is the configuration file that can be used to ease the integration of new services by providing a default selection of modules appropriate to the local security policy. Or, it can be used to deny access to any application that does not have a specific /etc/pam.d entry. The fields in the configuration file are module-type, control-flag and module-filename. Any other fields are optional arguments that are specific to the individual modules.

Default policy

If a system is to be considered secure, it had better have a reasonably secure other entry. The following is a paranoid setting (which is not a bad place to start!):

#
# default configuration: /etc/pam.d/other
#
auth required pam_deny.so
account required pam_deny.so
password required pam_deny.so
session required pam_deny.so

While fundamentally a secure default, this won’t give the administrator any feedback about a misconfigured system. For example, such a system is vulnerable to locking everyone out should the configuration file for a specific service be badly written.

The module pam_deny is not very sophisticated, it logs no information when it is invoked. Unless the users of a system contact the administrator when failing to execute a service application, the administrator may go for a long not knowing that his system is mis-configured.

By changing the configuration to the example below would provide a suitable warning to the administrator. Notice the the stacking of pam_warn.so and pam_deny.so.

#
# default configuration: /etc/pam.d/other
#
auth required pam_deny.so
auth required pam_warn.so
account required pam_deny.so
account required pam_warn.so
password required pam_deny.so 

password required pam_warn.so
session required pam_deny.so
session required pam_warn.so

With this configuration, whenever an unknown service attempts to access any of the four configuration types, PAM denies authentication (via the pam_deny.so module) and then logs a syslog warning (via the pam_warn.so module). Short of a bug in PAM, this configuration is brutally secure. The only problem with that brutality is it may cause problems if your accidentally delete the configuration of another service. If your /etc/pam.d/login was mistakenly deleted, no one would be able to login!

Here’s a little gentler configuration

#
# default configuration: /etc/pam.d/other
#
auth requisite pam_securetty.so
auth required pam_unix.so
auth required pam_warn.so
account required pam_unix.so
account required pam_warn.so
password required pam_unix.so
password required pam_warn.so
session required pam_unix.so
session required pam_warn.so.

The first module (pam_securetty.so) checks to see if the user is root and prevents root from logging in from an insecure terminal. The value requisite for control-flag is used to force immediate authentication failure if the securetty module fails. If this occurs, no more of the auth modules are executed. This has the benefit of preventing root from mistakenly typing a password over an insecure terminal line. This configuration will allow an unknown service to authenticate (via the pam_unix.so module), although it will not allow it to change the user’s password. Although it allows authentication by unknown services, it logs a syslog warning whenever such a service attempts authentication.

A word on null passwords

On many linux systems there are a number of accounts used to assign privileges to system services like ftp, apache, news, and databases. These accounts allow services to run as unprivileged users, providing a level of security, because an intruder that compromises the service only has the limited privileges available to that service, rather than the privileges of root. However, allowing these accounts login privileges is a security risk, as they usually have blank (null) passwords. The nullok options-argument allows passwordless accounts. It is recommended you remove this argument from any modules of auth type for services that allow login. This is usually the login service, may also include services like rlogin and ssh. So the following line in /etc/pam.d/login:

auth required pam_unix.so nullok

Should be changed to:

auth required pam_unix.so

Disable unused services

If you find you have pam configuration files in /etc/pam.d/ that you’re not using, you may want to rename or remove them to prevent their unauthorized use. For example, if you’re not using graphical login (Red Hat runlevel 5) then you might want to rename /etc/pam.d/xdm to /etc/pam.d/noxdm. Not finding the file named after the service requesting authentication, PAM will fall back to the /etc/pam.d/other. If you later want to enable the service, rename to it’s original name and everything will work as it was intended.

Basic PAM modules

pam_unix.so

This module provides traditional Unix authentication, password management, and user account setup. It uses standard system calls to retrieve and set password and account information, and relies on /etc/shadow and /etc/passwd.

  • accountEstablishes the validity of the user’s account and password and may offer advice on changing the user’s password, or force a password change. The actions this module performs are controlled by the /etc/passwd and /etc/shadow files.Arguments: audit, debug.
  • authThis component of the module checks the user’s password against the password databases. Configuration for this component is done in /etc/nsswitch.conf. An additional binary, unix_chkpwd, is used to allow the component to read protected databases without requiring the whole module to be setuid root.Arguments: audit, debug, nodelay, nullok, try_first_pass, use_first_pass.
  • passwordThis component changes the user’s password. The module pam_cracklib.so can be stacked with this component to check password security.Arguments: audit, bigcrypt, debug, md5, nis, not_set_pass, nullok, remember, try_first_pass, use_authtok, and use_first_pass.
  • sessionThis component logs the user name and session type to syslog, at the start and end of the user’s session. There are no arguments to this component.
  • arguments
    • audit A more extensive form of debug
    • bigcrypt Use the DEC “C2” extension to crypt().
    • debug – Log information using syslog
    • md5 – Use md5 encryption instead of crypt().
    • nis – Use NIS (Network Information Service) passwords.
    • nodelay – By default, the module requests a delay-on-failure of a second. This argument overrides the default.
    • not_set_pass – Don’t use the passwords from other stacked modules. Don’t give the new password to other stacked modules.
    • nullok – By default, if the official password is blank, the authentication fails. This argument overrides the default.
    • remember (remember=n) – Save n recent passwords to prevent the user from alternating passwords.
    • try_first_pass – Use the password from the previous stacked auth module, and prompt for a new password if the retrieved password is blank or incorrect.
    • use_authtok – Set the new password to the one provided by a previous module.
    • use_first_pass – Use the result from the previous stacked auth module, never prompts the user for a password, fails if the result was a fail.
pam_access.so

This module intercepts the user’s name and password. If the name is ftp or anonymous, the user’s password is broken up at the @ delimiter into a PAM_RUSER and a PAM_RHOST part; these pam-items being set accordingly. The username is set to ftp. In this case the module succeeds. Alternatively, the module sets the PAM_AUTHTOK item with the entered password and fails.

The behavior of the module can be modified with the following flags:

  • debug – log more information to with syslog(3).
  • users=XXX,YYY,… – instead of ftp or anonymous, provide anonymous login to the comma separated list of users; XXX,YYY,…. Should the applicant enter one of these usernames the returned username is set to the first in the list; “XXX”.
  • ignore – pay no attention to the email address of the user (if supplied).
pam_chroot.so

This module is intended to provide a transparent wrapper around the average user, one that puts them in a fake file-system (eg, their / is really /some/where/else

).

Useful if you have several classes of users, and are slightly paranoid about security. Can be used to limit who else users can see on the system, and to limit the selection of programs they can run.

pam_console.so

This module implements a console permission scheme similar to Solaris’ logindevperms. Allows for the permissioning of certain devices and files at login and logout time.

pam_cracklib.so

This module can be plugged into the password stack of a given application to provide some plug-in strength-checking for passwords.

This module works in the following manner:
it first calls the Cracklib routine to check the strength of the password; if crack likes the password, the module does an additional set of strength checks. These checks are:

  • Palindrome – Is the new password a palindrome of the old one?
  • Case Change Only – Is the new password the the old one with only a change of case?
  • Similar – Is the new password too much like the old one? This is primarily controlled by one argument, difok which is a number of characters that if different between the old and new are enough to accept the new password, this defaults to 10 or 1/2 the size of the new password whichever is smaller. To avoid the lockup associated with trying to change a long and complicated password, difignore is available. This argument can be used to specify the minimum length a new password needs to be before the difok value is ignored. The default value for difignore is 23.
  • Simple – Is the new password too small? This is controlled by 5 arguments minlen, dcredit, ucredit, lcredit, and ocredit. See the section on the arguments for the details of how these work and there defaults.
  • Rotated – Is the new password a rotated version of the old password?
  • Already used – Was the password used in the past? Previously used passwords are to be found in /etc/security/opasswd.

This module with no arguments will work well for standard unix password encryption. With md5 encryption, passwords can be longer than 8 characters and the default settings for this module can make it hard for the user to choose a satisfactory new password. Notably, the requirement that the new password contain no more than 1/2 of the characters in the old password becomes a non-trivial constraint. For example, an old password of the form the quick brown fox jumped over the lazy dogs would be difficult to change… In addition, the default action is to allow passwords as small as 5 characters in length. For a md5 systems it can be a good idea to increase the required minimum size of a password. One can then allow more credit for different kinds of characters but accept that the new password may share most of these characters with the old password.

pam_deny.so

This module can be used to deny access. It always indicates a failure to the application through the PAM framework. As is commented in the overview section above, this module might be suitable for using for default (the OTHER) entries.

pam_env.so

This module allows you to (un)set arbitrary environment variables using fixed strings, the value of previously set environment variables and/or PAM_ITEMs.

All is controlled via a configuration file (by default, /etc/security/pam_env.conf but can be overriden with conffile argument). Each line starts with the variable name, there are then two possible options for each variable DEFAULT and OVERRIDE. DEFAULT allows an administrator to set the value of the variable to some default value, if none is supplied then the empty string is assumed. The OVERRIDE option tells pam_env.so that it should enter in its value (overriding the default value) if there is one to use. OVERRIDE is not used, “” is assumed and no override will be done.

VARIABLE [DEFAULT=[value]] [OVERRIDE=[value]]

(Possibly non-existent) environment variables may be used in values using the ${string} syntax and (possibly non-existent) PAM_ITEMs may be used in values using the @{string} syntax. Both the $ and @ characters can be backslash-escaped to be used as literal values (as in \$. Double quotes may be used in values (but not environment variable names) when white space is needed the full value must be delimited by the quotes and embedded or escaped quotes are not supported.

This module can also parse a file with simple KEY=VAL pairs on separate lines (/etc/environment by default). You can change the default file to parse, with the envfile flag and turn it on or off by setting the readenv flag to 1 or 0 respectively.

The behavior of this module can be modified with one of the following flags:

  • debug write more information to syslog(3).
  • conffile=filename by default the file /etc/security/pam_env.conf is used as the configuration file. This option overrides the default. You must supply a complete path + file name.
  • envfile=filename by default the file /etc/environment is used to load KEY=VAL pairs directly into the env. This option overrides the default. You must supply a complete path + file name.
  • readenv=0|1 turns on or off the reading of the file specified by envfile (0 is off, 1 is on). By default this option is on.
pam_filter.so

Each component of the module has the potential to invoke the desired filter. The filter is always execv(2)d with the privilege of the calling application and not that of the user. For this reason it cannot usually be killed by the user without closing their session.

The behavior of the module can be significantly altered by the arguments passed to it in the Linux-PAM configuration file:

  • debug – this option increases the amount of information logged to syslog(3) as the module is executed.
  • new_term – the default action of the filter is to set the PAM_TTY item to indicate the terminal that the user is using to connect to the application. This argument indicates that the filter should set PAM_TTY to the filtered pseudo-terminal.
  • non_term – don’t try to set the PAM_TTY item.
  • runX – in order that the module can invoke a filter it should know when to invoke it. This argument is required to tell the filter when to do this. The arguments that follow this one are respectively the full pathname of the filter to be run and any command line arguments that the filter might expect.Permitted values for X are 1 and 2. These indicate the precise time that the filter is to be run. To understand this concept it will be useful to have read the Linux-PAM Module developer’s guide. Basically, for each management group there are up to two ways of calling the module’s functions.

In the case of the authentication and session components there are actually two separate functions. For the case of authentication, these functions are _authenticate and _setcred – here run1 means run the filter from the _authenticate function and run2 means run the filter from _setcred. In the case of the session modules, run1 implies that the filter is invoked at the _open_session stage, and run2 for _close_session.

For the case of the account component. Either run1 or run2 may be used.

For the case of the password component, run1 is used to indicate that the filter is run on the first occasion _chauthtok is run (the PAM_PRELIM_CHECK phase) and run2 is used to indicate that the filter is run on the second occasion (the PAM_UPDATE_AUTHTOK phase).

pam_ftp.so

This module intercepts the user’s name and password. If the name is ftp or anonymous, the user’s password is broken up at the @ delimiter into a PAM_RUSER and a PAM_RHOST part; these pam-items being set accordingly. The username (PAM_USER) is set to ftp. In this case the module succeeds. Alternatively, the module sets the PAM_AUTHTOK item with the entered password and fails.

The behavior of the module can be modified with the following flags:

  • debug – log more information to with syslog(3).
  • users=XXX,YYY,… – instead of ftp or anonymous, provide anonymous login to the comma separated list of users; XXX,YYY,…. Should the applicant enter one of these usernames the returned username is set to the first in the list; XXX.
  • ignore – pay no attention to the email address of the user (if supplied).
pam_group.so

This module does not authenticate the user, but instead it grants group memberships (in the credential setting phase of the authentication module) to the user. Such memberships are based on the service they are applying for. The group memberships are listed in text form in the /etc/security/group.conf file.

pam_issue.so

This module allows you to prepend an issue file to the username prompt. It also by default parses escape codes in the issue file similar to some common getty’s (using \x format).

Recognized escapes:

  • d – current date
  • s – operating system name
  • l – name of this tty
  • m – architecture of this system (i686, sparc, powerpc, …)
  • n – hostname of this system
  • o – domainname of this system
  • r – release number of the operation system (eg. 2.2.12)
  • t – current time
  • u – number of users currently logged in
  • U – same as u, except it is suffixed with “user” or “users” (eg. “1 user” or “10 users”
  • v – version/build-date of the operating system (eg. “#3 Mon Aug 23 14:38:16 EDT 1999” on Linux).

The behavior of this module can be modified with one of the following flags:

  • issue – the file to output if not using the default
  • noesc – turns off escape code parsing
pam_krb5.so

pam_krb5.so is designed to allow smooth integration of Kerberos 5 password- checking with applications built using PAM. It also supports session-specific ticket files (which are neater), and Kerberos IV ticket file grabbing. Its main use is as an authentication module, but it also supplies the same functions as a session-management module to better support poorly-written applications, and a couple of other workarounds as well. It also supports account management and password-changing.

When a user logs in, the module’s authentication function performs a simple password check and, if possible, obtains Kerberos 5 and Kerberos IV credentials, caching them for later use. When the application requests initialization of credentials (or opens a session), the usual ticket files are created. When the application subsequently requests deletion of credentials or closing of the session, the module deletes the ticket files.

pam_lastlog.so

This module can be used to provide a Last login on … message. when the user logs into the system from what ever application uses the PAM libraries. In addition, the module maintains the /var/log/lastlog file.

The behavior of this module can be modified with one of the following flags:

  • debug – write more information to syslog(3).
  • nodate – neglect to give the date of the last login when displaying information about the last login on the system.
  • noterm – neglect to diplay the terminal name on which the last login was attempt.
  • nohost – neglect to indicate from which host the last login was attempted.
  • silent – neglect to inform the user about any previous login: just update the /var/log/lastlog file.
  • never – if the /var/log/lastlog file does not contain any old entries for the user, indicate that the user has never previously logged in with a welcome… message.
pam_ldap.so

This is a relatively new module that allows the use of ldap instead of something like NIS or NIS+ to do distributed authentication.

pam_limits.so

Through the contents of the configuration file, /etc/security/limits.conf, resource limits are placed on users’ sessions. Users of uid=0 are not affected by this restriction.

The behavior of this module can be modified with the following arguments:

  • debug – verbose logging to syslog(3).
  • conf=/path/to/file.conf – indicate an alternative limits configuration file to the default.
  • change_uid – change real uid to the user for who the limits are set up. Use this option if you have problems like login not forking a shell for user who has no processes. Be warned that something else may break when you do this.
  • utmp_early – some broken applications actually allocate a utmp entry for the user before the user is admitted to the system. If some of the services you are configuring PAM for do this, you can selectively use this module argument to compensate for this behavior and at the same time maintain system-wide consistency with a single limits.conf file.
pam_listfile

The module gets the item of the type specified – user specifies the username, PAM_USER; tty specifies the name of the terminal over which the request has been made, PAM_TTY; rhost specifies the name of the remote host (if any) from which the request was made, PAM_RHOST; and ruser specifies the name of the remote user (if available) who made the request, PAM_RUSER – and looks for an instance of that item in the file filename. filename contains one line per item listed. If the item is found, then if sense=allow, PAM_SUCCESS is returned, causing the authorization request to succeed; else if sense=deny, PAM_AUTH_ERR is returned, causing the authorization request to fail.

If an error is encountered (for instance, if filename does not exist, or a poorly-constructed argument is encountered), then if onerr=succeed, PAM_SUCCESS is returned, otherwise if onerr=fail, PAM_AUTH_ERR or PAM_SERVICE_ERR (as appropriate) will be returned.

An additional argument, apply=, can be used to restrict the application of the above to a specific user (apply=username) or a given group (apply=@groupname). This added restriction is only meaningful when used with the tty, rhost and shell items.

Besides this last one, all arguments should be specified; do not count on any default behavior, as it is subject to change.

No credentials are awarded by this module.

Classic ftpusers authentication can be implemented with this entry in /etc/pam.d/ftp

auth required pam_listfile.so onerr=succeed item=user sense-deny
file=/etc/ftpusers

Note, users listed in /etc/ftpusers file are (counterintuitively) not allowed access to the ftp service.

pam_mail.so

This module provides the you have new mail service to the user. It can be plugged into any application that has credential hooks. It gives a single message indicating the newness of any mail it finds in the user’s mail folder. This module also sets the Linux-PAM environment variable, MAIL, to the user’s mail directory.

The behavior of this module can be modified with one of the following flags:

  • debug – write more information to syslog(3).
  • dir=pathname – look for the users’ mail in an alternative directory given by pathname. The default location for mail is /var/spool/mail. Note, if the supplied pathname is prefixed by a `’, the directory is interpreted as indicating a file in the user’s home directory.
  • nopen – instruct the module to not print any mail information when the user’s credentials are acquired. This flag is useful to get the MAIL environment variable set, but to not display any information about it.
  • close – instruct the module to indicate if the user has any mail at the as the user’s credentials are revoked.
  • noenv – do not set the MAIL environment variable.
  • empty – indicate that the user’s mail directory is empty if this is found to be the case.
  • hash=hashcount – mail directory hash depth. For example, a hashcount of 2 would make the mailfile be /var/spool/mail/u/s/user.
  • standard – old style “You have…” format which doesn’t show the mail spool being used. this also implies empty
  • quiet – only report when there is new mail.
pam_mkhomedir.so

This module is useful for distributed systems where the user account is managed in a central database (such as NIS, NIS+, or LDAP) and accessed through multiple systems. It frees the administrator from having to create a default home directory on each of the systems by creating it upon the first successfully authenticated login of that user. The skeleton directory (usually /etc/skel/) is used to copy default files and also set’s a umask for the creation.

The behavior of this module can be modified with one of the following flags:

  • skel – The skeleton directory for default files to copy to the new home directory.
  • umask – An octal for of the same format as you would pass to the shells umask command.
pam_motd.so

This module allows you to have arbitrary motd’s (message of the day) output after a successful login. By default this file is /etc/motd, but is configurable to any file.

The behavior of this module can be modified with one of the following flags:

  • motd – the file to output if not using the default.
pam_nologin.so

Provides standard Unix nologin authentication. If the file /etc/nologin exists, only root is allowed to log in; other users are turned away with an error message (and the module returns PAM_AUTH_ERR or PAM_USER_UNKNOWN). All users (root or otherwise) are shown the contents of /etc/nologin.

If the file /etc/nologin does not exist, this module defaults to returning PAM_IGNORE, but the successok module argument causes it to return PAM_SUCCESS in this case.

The administrator can override the default nologin file with the file=pathname module argument.

pam_permit.so

No matter what management group, the action of this module is to simply return PAM_SUCCESS – operation successful.

In the case of authentication, the user’s name will be acquired. Many applications become confused if this name is unknown.

pam_pwdb.so

This module is a pluggable replacement for the pam_unix_.. modules. It uses the generic interface of the Password Database library libpwdb.

The debug argument makes the accounting functions of this module syslog(3) more information on its actions. (Remaining arguments supported by the other functions of this module are silently ignored, but others are logged as errors through syslog(3)).

Based on the following pwdb_elements: expire; last_change; max_change; defer_change; warn_change, this module performs the task of establishing the status of the user’s account and password. In the case of the latter, it may offer advice to the user on changing their password or, through the PAM_AUTHTOKEN_REQD return, delay giving service to the user until they have established a new password. The entries listed above are documented in the Password Database Library Guide (see pointer above). Should the user’s record not contain one or more of these entries, the corresponding shadow check is not performed.

pam_rhosts_auth.so

his module performs the standard network authentication for services, as used by traditional implementations of rlogin and rsh etc.

The authentication mechanism of this module is based on the contents of two files; /etc/hosts.equiv (or _PATH_HEQUIV in #include ) and /.rhosts. Firstly, hosts listed in the former file are treated as equivalent to the localhost. Secondly, entries in the user’s own copy of the latter file is used to map remote-host remote-user pairs to that user’s account on the current host. Access is granted to the user if their host is present in /etc/hosts.equiv and their remote account is identical to their local one, or if their remote account has an entry in their personal configuration file.

Some restrictions are applied to the attributes of the user’s personal configuration file: it must be a regular file (as defined by S_ISREG(x) of POSIX.1); it must be owned by the superuser or the user; it must not be writable by any user besides its owner.

The module authenticates a remote user (internally specified by the item PAM_RUSER) connecting from the remote host (internally specified by the item PAM_RHOST). Accordingly, for applications to be compatible this authentication module they must set these items prior to calling pam_authenticate(). The module is not capable of independently probing the network connection for such information.

In the case of root-access, the /etc/host.equiv file is ignored unless the hosts_equiv_rootok option should be used. Instead, the superuser must have a correctly configured personal configuration file.

The behavior of the module is modified by flags:

  • debug – log more information to syslog(3). (XXX – actually, this module does not do any logging currently, please volunteer to fix this!)
  • no_warn – do not give verbal warnings to the user about failures etc. (XXX – this module currently does not issue any warnings, please volunteer to fix this!)
  • no_hosts_equiv – ignore the contents of the /etc/hosts.equiv file.
  • hosts_equiv_rootok – allow the use of /etc/hosts.equiv for superuser. Without this option /etc/hosts.equiv is not consulted for the superuser account. This option has no effect if the no_hosts_equiv option is used.
  • no_rhosts – ignore the contents of all user’s personal configuration file /.rhosts.
  • privategroup – normally, the /.rhosts file must not be writable by anyone other than its owner. This option overlooks group write access in the case that the group owner of this file has the same name as the user being authenticated. To lessen the security problems associated with this option, the module also checks that the user is the only member of their private group.
  • promiscuous – A host entry of `+’ will lead to all hosts being granted access. Without this option, ‘+’ entries will be ignored. Note, that the debug option will syslog a warning in this latter case.
  • suppress – This will prevent the module from syslog(3)ing a warning message when this authentication fails. This option is mostly for keeping logs free of meaningless errors, in particular when the module is used with the sufficient control flag.
pam_rootok.so

This module is for use in situations where the superuser wishes to gain access to a service without having to enter a password.

This module authenticates the user if their uid is 0. Applications that are created setuid-root generally retain the uid of the user but run with the authority of an enhanced effective-uid. It is the real uid that is checked.

pam_securetty.so

Provides standard Unix securetty checking, which causes authentication for root to fail unless PAM_TTY is set to a string listed in the /etc/securetty file. For all other users, it succeeds.

For canonical usage, should be listed as a required authentication method before any sufficient authentication methods.

pam_shells.so

This module checks for the existence of a user’s shell in /etc/shells

pam_stack.so

from the man page

In a nutshell, pam_stack lets you “call”, from inside of the stack for a particular service, the stack defined for any another service. The intention is to allow multiple services to “include” a system-wide setup, so that when that setup needs to be changed, it need only be changed in one place.

pam_stress.so

A stress testing PAM module

pam_tally.so

This module maintains a count of attempted accesses, can reset count on success, can deny access if too many attempts fail.

pam_tally comes in two parts: pam_tally.so and pam_tally. The former is the PAM module and the latter, a stand-alone program. pam_tally is an (optional) application which can be used to interrogate and manipulate the counter file. It can display users’ counts, set individual counts, or clear all counts. Setting artificially high counts may be useful for blocking users without changing their passwords. For example, one might find it useful to clear all counts every midnight from a cron job.

The counts file is organized as a binary-word array, indexed by uid. You can probably make sense of it with od, if you don’t want to use the supplied application.

Note, there are some outstanding issues with this module: pam_tally is very dependent on getpw*() – a database of usernames would be much more flexible; the `keep a count of current logins’ bit has been #ifdef’d out and you can only reset the counter on successful authentication, for now.

The authentication component of this module increments the attempted login counter.

pam_time.so

Running a well regulated system occasionally involves restricting access to certain services in a selective manner. This module offers some time control for access to services offered by a system. Its actions are determined with a configuration file. This module can be configured to deny access to (individual) users based on their name, the time of day, the day of week, the service they are applying for and their terminal from which they are making their request.

This module bases its actions on the rules listed in its configuration file: /etc/security/time.conf. Each rule has the following form,

services;ttys;users;times

In words, each rule occupies a line, terminated with a newline or the beginning of a comment; a `#’. It contains four fields separated with semicolons, `;’. The fields are as follows:

  • services – a logic list of service names that are affected by this rule.
  • ttys – a logic list of terminal names indicating those terminals covered by the rule.
  • user – a logic list of usernames to which this rule applies

By a logic list we mean a sequence of tokens (associated with the appropriate PAM_ item), containing no more than one wildcard character; `*’, and optionally prefixed with a negation operator; `!’. Such a sequence is concatenated with one of two logical operators: & (logical AND) and | (logical OR). Two examples are: !morgan&!root, indicating that this rule does not apply to the user morgan nor to root; and tty*&!ttyp*, which indicates that the rule applies only to console terminals but not pseudoterminals.

  • times – a logic list of times at which this rule applies. The format of each element is a day/time-range. The days are specified by a sequence of two character entries. For example, MoTuSa, indicates Monday Tuesday and Saturday. Note that repeated days are unset; MoTuMo indicates Tuesday, and MoWk means all weekdays bar Monday. The two character combinations accepted are,Mo Tu We Th Fr Sa Su Wk Wd Al

    The last two of these being weekend days and all 7 days of the week respectively.

    The time range part is a pair of 24-hour times, HHMM, separated by a hyphen – indicating the start and finish time for the rule. If the finish time is smaller than the start time, it is assumed to apply on the following day. For an example, Mo1800-0300 indicates that the permitted times are Monday night from 6pm to 3am the following morning.

    Note, that the given time restriction is only applied when the first three fields are satisfied by a user’s application for service.

For convenience and readability a rule can be extended beyond a single line with a `\newline’.

pam_unix.so

This is the standard Unix authentication module. It uses standard calls from the system’s libraries to retrieve and set account information as well as authentication. Usually this is obtained from the /etc/passwd and the /etc/shadow file as well if shadow is enabled.

The debug argument makes the accounting functions of this module syslog(3) more information on its actions. (Remaining arguments supported by the other functions of this module are silently ignored, but others are logged as errors through syslog(3)). The audit argument causes even more logging.

Based on the following shadow elements: expire; last_change; max_change; min_change; warn_change, this module performs the task of establishing the status of the user’s account and password. In the case of the latter, it may offer advice to the user on changing their password or, through the PAM_AUTHTOKEN_REQD return, delay giving service to the user until they have established a new password. The entries listed above are documented in the GNU Libc info documents. Should the user’s record not contain one or more of these entries, the corresponding shadow check is not performed.

pam_userdb.so

Look up users in a .db database and verify their password against what is contained in that database.

This module is used to verify a username/password pair against values stored in a Berkeley DB database. The database is indexed by the username, and the data fields corresponding to the username keys are the passwords, in unencrypted form, so caution must be exercised over the access rights to the DB database itself..

The module will read the password from the user using the conversation mechanism. If you are using this module on top of another authentication module (like pam_pwdb😉 then you should tell that module to read the entered password from the PAM_AUTHTOK field, which is set by this module.

The action of the module may be modified from this default by one or more of the following flags in the /etc/pam.d/ file.

  • debug – Supply more debugging information to syslog(3).
  • icase – Perform the password comparisons case insensitive.
  • dump – dump all the entries in the database to the log (eek, don’t do this by default!)
  • db=XXXX – use the database found on pathname XXXX. Note that Berkeley DB usually adds the needed filename extension for you, so you should use something like /etc/foodata instead of /etc/foodata.db.
pam_warn.so

This module is principally for logging information about a proposed authentication or application to update a password.

Log the service, terminal, user, remote user and remote host to syslog(3). The items are not probed for, but instead obtained from the standard pam-items.

pam_wheel.so

This module is used to enforce the so-called wheel group. By default, it permits root access to the system if the applicant user is a member of the wheel group (better described as the group with group-id 0).

The action of the module may be modified from this default by one or more of the following flags in the /etc/pam.conf file.

  • debug – Supply more debugging information to syslog(3).
  • use_id – This option modifies the behavior of the module by using the current uid of the process and not the getlogin(3) name of the user. This option is useful for being able to jump from one account to another, for example with ‘su’.
  • trust – This option instructs the module to return PAM_SUCCESS should it find the user applying for root privilege is a member of the wheel group. The default action is to return PAM_IGNORE in this situation. By using the trust option it is possible to arrange for wheel-group members to become root without typing a password. USE WITH CARE.
  • deny – This is used to reverse the logic of the module’s behavior. If the user is trying to get uid=0 access and is a member of the wheel group, deny access (for the wheel group, this is perhaps nonsense!): it is intended for use in conjunction with the group= argument…
  • group=XXXX – Instead of checking the gid=0 group, use the user’s XXXX group membership for the authentication. Here, XXXX is the name of the group and not its numeric identifier.

To allow only members of the wheel group to become root through su, use the following line in /etc/pam.d/su:

auth required /lib/security/pam_wheel.so use_uid
pam_warn.so

This module logs information about an authentication or password change attempt to syslog.

This module has no arguments, and only auth and password components. Log the service, terminal, user, remote user and remote host to syslog(3). The items are not probed for, but instead obtained from the standard pam-items.

pam_xauth.so

This module is designed to forward xauth keys (sometimes referred to as “cookies”) between users.

Without pam_xauth, when xauth is enabled and a user uses the su command to assume superuser privileges, that user is not able to run X commands as root without somehow giving root access to the xauth key used for the current X session. pam_xauth solves the problem by forwarding the key from the user running su (the source user) to the user whose identity the source user is assuming (the target user) when the session is created, and destroying the key when the session is torn down.

Resources:

1) http://www.freebsd.org/doc/en_US.ISO8859-1/articles/pam/

2) http://www.kernel.org/pub/linux/libs/pam/FAQ

3) http://tldp.org/HOWTO/User-Authentication-HOWTO/index.html

4) http://www.linuxgeek.net/documentation/authentication#SECTION05010000000000000000

Hope this will help.

Cheers!

Bhaskar

About unixbhaskar
GNU/Linux Consultant

3 Responses to PAM : Pluggable Authentication Modules

  1. Pingback: Wordpress network and ldap | Hi Tech Stuff Reviews & Updates

  2. Pingback: Links 5/10/2010: Marvell Gives OLPC $5.6 Million | Techrights

  3. haarausfall says:

    Wonderful article! We are linking to this great post on our site.

    Keep up the great writing.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: