Chapter 25
PAM - Pluggable Authentication Modules
|
|
|
|
|
 |
In this chapter: |
|
|
|
  |
Understanding the principles of PAM
|
  |
Learnign about the most important PAM modules
|
  |
Discussing an example
|
|
|
|
 |
|
Since the beginnings of Unix, authenticating a user has been
accomplished via the user entering a password and the system checking
if the entered password corresponds to the encrypted official password
that is stored in the user database /etc/passwd. The idea
being that the user is really that user if and only if they can
correctly enter their secret password.
That was in the beginning. Since then, a number of new ways of
authenticating users have become popular. Including more complicated
replacements for the /etc/passwd file (shadow passwords),
and hardware devices Smart cards etc..
The problem is that each time a new authentication scheme is
developed, it requires all the necessary programs (login,
ftpd etc...) to be rewritten to support it.
PAM provides a way to develop programs that are independent of
authentication scheme. These programs need authentication
modules to be attatched to them at run-time in order to
work. Which authentication module is to be attatched is dependent upon
the local system setup and is at the discretion of the local system
administrator.
SuSE integrated PAM starting with version 6.2 of their
distribution. The integration was fairly transparent to the user. This
means no new authentication schemes were set as defaults, everything
is working just as it was with older releases. But starting with 6.2
you got an easy way to change the authentication scheme for single
services, or for all services requiering authentication at once.
|
25.1 | The PAM configuration scheme |
|
PAM is designed to provide the system administrator with a great deal
of flexibility in configuring the privilege granting applications of
their system. The local configuration of those aspects of system
security controlled by PAM is contained in the /etc/pam.d
directory. In this section we discuss the correct syntax of and
generic options respected by entries to these files.
When you look into the directory /etc/pam.d, you'll see a
list of files. Each file refers to a service that requieres some kind
of authentification. The names of the files in /etc/pam.d
usually match the name of the service they configure. So is
/etc/pam.d/login the configuration file for the
login(1) application, passwd configures the
passwd(1) utility, and so on.
It is possible to symbolically link different services configuration
files to a single file. This makes it easier to keep the system policy
for access consistent across different applications. You can limit
read access to individual PAM configuration files using the file
protections of the filesystem as an easy way to limit services
only to specific groups of users.
|
25.2 | The configuration file syntax |
|
A general configuration line of the /etc/pam.d/* files has the
following form:
|
|
module-type control-flag module-path arguments
|
|
|
25.2.1 | Module Type |
|
One of (currently) four types of modules:
|
|
  |
auth
This module type provides two aspects of authenticating the
user. Firstly, it establishes that the user is who they claim to
be, by instructing the application to prompt the user for a password
or other means of identification. Secondly, the module can grant
group membership (independently of the /etc/groups
file) or other privileges through its credential granting
properties.
|
  |
account
This module performs non-authentication based account management. 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 applicant user (i.e. `root' login
only on the console).
|
  |
session
Primarily, this module is associated with doing things that need to be
done for the user before/after they can be given service. Such things
include the logging of information concerning the opening/closing of
some data exchange with a user, mounting directories, etc.
|
  |
password
This last module type is required for updating the authentication
token associated with the user. Typically, there is one module for
each challenge/response based authentication (auth) module-type.
|
|
|
|
25.2.2 | 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. Instead, it receives a
summary success or fail response from the 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 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 ssociated with the
success or failure of a specific module. There are four such keywords:
required, requisite, sufficient
and optional.
The 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, however, in the case that 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.
|
 |
Note that 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
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. (Note, 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, 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.
|
|
|
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 delimeted with square
brackets and consists of a series of value=action
tokens. As SuSE uses the traditional syntax, this chapter will be
restricted to the discussion of the traditional way to configure
PAM. Please refer to the PAM documentaion (either online or in the
directory /usr/doc/packages/pam) to learn about the new
configuration syntax.
|
25.2.3 | Module path and arguments |
|
The path-name 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. You will see descriptions of the
most important modules in the next section.
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).
Most modules recognize a set of generic arguments:
|
|
  |
debug
Use 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).
|
  |
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.
|
|
|
The module specific arguments are discussed in the next section, when we
see which modules are available.
|
25.3 | PAM modules |
|
You learned in the previous section, that PAM is organized around
modules resposibe for different tasks of user authentification. In
this section we'll list the modules used by the SuSE standard
installation. Please note, that there are more modules available than
discussed in this section. Refer to the PAM documentation (online or
in /usr/doc/packages/pam) to learn more about modules not
listed here.
|
25.3.1 | Set/unset environment variables: 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.
This is controlled by a configuration file (by default,
/etc/security/pam_env.conf but can be overriden with the
conffile argument). Each line starts with the variable
name, there are then two possible options for each variable
DEFAULT and OVERRIDE.
|
|
VARIABLE [DEFAULT=[value]] [OVERRIDE=[value]]
|
|
The token DEFAULT allows the administrator to set the
value of the variable to some default value, if none is supplied then
the empty string is assumed. The OVERRIDE token tells
pam_env that it should override the default 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 seperate 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 and 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 and 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.
|
|
|
|
25.3.2 | Anonymous access module: 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 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.
|
  |
ignore
Pay no attention to the email address of the user (if supplied).
|
|
|
|
25.3.3 | The resource limits module: pam_limits.so |
|
This module, through the PAM open-session hook, sets limits on the
system resources that can be obtained in a user session. Its actions
are dictated more explicitly through the configuration file
/etc/security/limits.conf. Through the contents of the
configuration file resource limits are placed on users' sessions. The
user root is not affected by this restriction.
In order to use this module the system administrator must first create
a root-only-readable file (default is
/etc/security/limits.conf). This file describes the
resource limits the superuser wishes to impose on users and groups.
Each line of the configuration file describes a limit for a user in the form:
|
|
domain type item value
|
|
The value of domain can be a username, a groupname, with
@group syntax or the wild-card * to specify
the default entry.
The field type can have the two values:
|
|
  |
hard for enforcing hard resource limits. These limits are
set by the superuser and enforced by the Linux Kernel. The user cannot
raise his requirement of system resources above such values.
|
  |
soft for enforcing soft resource limits. These limits
are ones that the user can move up or down within the permitted range
by any pre-exisiting hard limits. The values specified with this token
can be thought of as default values, for normal system usage.
|
|
|
To specify the kind of resource you want to limit, you set
item to one of the following:
|
|
  |
core - limits the core file size (KB)
|
  |
data - max data size (KB)
|
  |
fsize - maximum filesize (KB)
|
  |
memlock - max locked-in-memory address space (KB)
|
  |
nofile - max number of open files
|
  |
rss - max resident set size (KB)
|
  |
stack - max stack size (KB)
|
  |
cpu - max CPU time (MIN)
|
  |
nproc - max number of processes
|
  |
as - address space limit
|
  |
maxlogins - max number of logins for this user
|
  |
priority - the priority to run user process with
|
|
|
To completely disable limits for a user (or a group), a single dash
(-) will do. Please remember that individual limits have
priority over group limits, so if you impose no limits for admin
group, but one of the members in this group have a limits line, the
user will have its limits set according to this line.
Also, please note that all limit settings are set per login. They are
not global, nor are they permanent; existing only for the duration of
the session.
In the limits configuration file, the # character
introduces a comment - after which the rest of the line is ignored.
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. The default
is /etc/security/limits.conf.
|
|
|
|
25.3.4 | The list-file module: pam_listfile.so |
|
The list-file module provides a way to deny or allow services based on
an arbitrary file. Other than the modules discussed so far, this
module does not have a configuration file. The behavoiur is
controlled by it's command line options only. The module recognizes
the following parameters:
|
|
  |
onerr=succeed|fail
|
  |
sense=allow|deny
|
  |
file=filename
|
  |
item=user|tty|rhost|ruser|group|shell
|
  |
apply=user|@group
|
|
|
The module denies or allows the access based on local or remote user
name, terminal, remote host name, group or login shell. You specify
this using the item paramter. Then the module looks for
an instance of that item in the file specified by
filename. This file contains one line per item listed. If
the item is found, then if sense is set to
allow, PAM_SUCCESS is returned, causing the
authorization request to succeed. Else if sense is set to
deny, PAM_AUTH_ERR is returned by the
module, causing the authorization request to fail.
If an error is encountered (for instance, if the file does not exist,
or a poorly-constructed argument is encountered), then if
onerr is succeed, PAM_SUCCESS is
returned, otherwise if onerr equals fail,
PAM_AUTH_ERR or PAM_SERVICE_ERR (as
appropriate) will be returned.
The 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.
Here is a list of the values for the item parameter:
|
|
  |
user specifies the username, PAM_USER;
|
  |
tty specifies the name of the (local) 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;
|
  |
ruser specifies the name of the remote user (if
available) who made the request, PAM_RUSER;
|
  |
shell specifies the users login shell;
|
  |
group specifies the default group the user belongs to;
|
|
|
|
25.3.5 | The mail module: 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 PAM
environment variable, MAIL, to the user's mail directory.
Although the module supplies functions for the authentication
management group of functions, it cannot be used to authenticate a
user; its authentication function instructs libpam to
simply ignore it when authenticating the user.
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 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.
|
|
|
|
25.3.6 | The no-login module: 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. All users (root or
otherwise) are shown the contents of /etc/nologin.
If the file /etc/nologin does not exist, this module
succeeds silently.
In order to make this module effective, all login methods should be
secured by it. It should be used as a required method
listed before any sufficient methods in order to get standard Unix
nologin semantics.
|
25.3.7 | The promiscuous module: pam_permit.so |
|
This module is very dangerous. It should be used with extreme
caution. Its action is always to permit access. It does nothing else.
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.
It is seldom a good idea to use this module. However, it does have
some legitimate uses. For example, if the system-administrator wishes
to turn off the account management on a workstation, and at the same
time continue to allow logins, then this module should be used.
|
25.3.8 | The rhosts module: pam_rhosts_auth.so |
|
This 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 the files /etc/hosts.equiv 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; it must be owned by the
superuser (root) or the user; it must not be writable by
any user besides its owner.
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 the following flags:
|
|
  |
debug - log more information to syslog(3). (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. (same as above, 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 write a warning entry to /var/log/messages
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.
|
|
|
|
25.3.9 | The root access module: 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 user ID is 0. Applications
that are created setuid-root generally retain the user ID of the user
but run with the authority of an enhanced effective-uid. It is the
real uid that is checked.
In the case of the su application the historical usage is
to permit the superuser to adopt the identity of a lesser user without
the use of a password. To obtain this behavior under PAM this module
should be used.
|
25.3.10 | The securetty module: pam_securetty.so |
|
This module provides standard Unix securetty checking, which causes
authentication for the superuser (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.
|
25.3.11 | The login shell module: pam_shells.so |
|
This module checks if the users login-shell (like listed in
/etc/passwd) is a valid login-shell. Authentication is
granted if the users shell is listed in /etc/shells. If
no shell is in /etc/passwd (empty), the
/bin/sh is used (following ftpd's convention).
This module also makes sure that /etc/shells is a plain
file and not world writable. The file /etc/shells is a
text file which contains the full pathnames of valid login shells.
|
25.3.12 | General authentification module: pam_unix.so |
|
This module provides basic password authentification and session
management. It is used my almost all services connected to the PAM
subsystem.
Depended on the module-type flag this module serves different
purposes. As account component (module type account) it
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.
When the module is called as authentication component (module-type
auth), it verifies user name and password in the systems
user database.
The third component of this module is the password mode (module-type
password). In this mode it's function is to store the
password in the systems user database.
Last but not least you can use tha module as session component
(module-type session). Here its action is simply to log
the username and the service-type to syslog(3). Messages
are logged at the beginning and end of the user's session.
The following options are recognized:
|
|
  |
debug - log more debugging info
|
  |
audit - a little more extreme than debug
|
  |
use_first_pass - don 't prompt the user for passwords
take them from PAM_ items instead
|
  |
try_first_pass - don 't prompt the user for the
passwords unless PAM_(OLD)AUTHTOK is unset
|
  |
use_authtok - like try_first_pass, but fail if
the new PAM_AUTHTOK has not been previously set. (intended for
stacking password modules only)
|
  |
not_set_pass - don 't set the PAM_ items with the
passwords used by this module.
|
  |
shadow - try to maintian a shadow based system.
|
  |
md5 - when a user changes their password next,
encrypt it with the md5 algorithm.
|
  |
bigcrypt - when a user changes their password next,
excrypt it with the DEC C2 - algorithm.
|
  |
nodelay - used to prevent failed authentication
resulting in a delay of about 1 second.
|
  |
nis - use NIS RPC for setting new password
|
  |
nullok - The default action of this module is to not
permit the user access to a service if their official password is
blank. The nullok argument overrides this default.
|
  |
remember=X - remember X old passwords, they are kept
in /etc/security/opasswd in MD5 crypted form
|
|
|
For compatibility with old versions this module is linked to the
following names:
|
|
  |
pam_unix_auth: authentication module providing
pam_authenticate() and pam_setcred() hooks
|
  |
pam_unix_sess: session module, providing sessionlogging
|
  |
pam_unix_acct: account management, providing shadow
account managment features, password aging etc..
|
  |
pam_unix_passwd: password updating facilities providing
cracklib password strength checking facilities.
|
|
|
|
25.3.13 | Warning logger module: pam_warn.so |
|
This module logs information about the remote user and host (if
pam-items are known).
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.
|
25.4 | Some examples |
|
In the previous sections you learned about the general syntax of the
PAM configuration and about the function and syntax of the individual
modules. Now it's time to look at some examples to see how the modules
work togehter in order to guarante a secure system. Like said before,
SuSE has individual configuration files for each service in the
directory /etc/pam.d.
|
25.4.1 | Logging into the system |
|
The most used service is the authentification of general user
logins. Users have to identify themselfes to the login
application. This utility asks for a user name and the referring
password and then establishes a new session with the system.
The PAM settings for login is located in
/etc/pam.d/login, which default configuration is shown
here:
|
|
auth requisite /lib/security/pam_unix.so nullok
auth required /lib/security/pam_securetty.so
auth required /lib/security/pam_nologin.so
auth required /lib/security/pam_env.so
auth required /lib/security/pam_mail.so
account required /lib/security/pam_unix.so
password required /lib/security/pam_unix.so strict=false
session required /lib/security/pam_unix.so none # debug or trace
session required /lib/security/pam_limits.so
|
|
You see the first five lines are handling the authentification of the
user, the module-type is set to auth. The module
pam_unix.so is called to get user name and password. The
flag nullok allows user with no assignd password to log
in. The control-flag requisite assigns PAM to return to
the login application in case the authentification fails, without
visiting any other PAM modules.
In case the user passes the initial authentification and a superuser
(root) login is detected, the module
pam_securetty.so verifies that the terminal from which
the login attempt is done, is listed in the file
/etc/securetty. The next module,
pam_nologin.so checks the existence of the file
/etc/nologin and denies logins for regular users (non
root) in case this file exists. The final
authentification module prints the you have mail
message if the user mailbox in not empty.
The next three lines all call the module pam_unix.so. You
see all modes of this module are used in this constellation. After the
module was used to check if the users name and password are valid (at
the very beginning of the configuration file), now the account
component is used to check if the users password is about to expire
and prompt the user for a new password if this is the case. In case
the user changed the password, it'll be written to the user database
in the next line, using the password component of
pam_unix.so. The last instance (session mode) makes an
entry in /var/log/messages reporting the users login
attempt.
The last line in this configuration sets the user limits for several
system resources.
You see that a simple looking task, like logging into the system is
in fact a fairly complex concatenation of events. This example
demomstartes how you can use PAM to exactly define how the system
should react to different conditions determined in the process of
logging in.
|
25.4.2 | Changing the password |
|
This example shows that changing the password requires basically the
same actions as logging into the system. First the user has to
prove his identity, then the user database has to be checked if a
password change is permitted (you may set the time to pass between
password changes). If the password was changed, it has to be written
to the user database and finally a log entry is made to note the
password change.
Keeping this in mind it's not surprising to see the same instances of
pam_unix.so in /etc/pam.d/passwd as we saw
them ealier in the configuration for the login utility:
|
|
auth required /lib/security/pam_unix.so nullok
account required /lib/security/pam_unix.so
password required /lib/security/pam_unix.so strict=false
session required /lib/security/pam_unix.so
|
|
|
25.4.3 | Run a command with substitute user and group ID |
|
The su allows one user to temporarily become another
user. It runs a command (often an interactive shell) with the real
and effective user ID, group ID, and supplemental groups of a given
user.
In order to do this the other users password must be known and
su prompts for the password before it executes the given
command. This is the case fopr every user but root. The
superuser can change identity without knowing the password.
For PAM this means that in case root calls
su it should not prompt for a password, but if anybody
else calls su a password has to be provided.
This is reflected by su's PAM configuration:
|
|
auth sufficient /lib/security/pam_rootok.so
auth required /lib/security/pam_unix.so nullok #set_secrpc
account required /lib/security/pam_unix.so
password required /lib/security/pam_unix.so #strict=false
session required /lib/security/pam_unix.so debug # trace or none
|
|
Again you see the four instances of pam_unix.so. But you
also see that they are only called if the module
pam_rootok.so fails. This means, if PAM detects that
root calls su it is satisfied and doesn't
prompt for a password. Otherwise the same authentificaton takes place
as if the user logs in for the first time.
But you also see the difference to the first example, where additional
checks (secure terminal, nologin) were performed and limits and
environment were intitialized. If you like, you can change the
su settings to perform the same tasks.
|
 |
Summary: |
|
The Pluggable Authentication Modules (PAM) provide an very flexibel
way of realising different kind of authentification scemes without the
need to change the application requesting the authentication. Modules
are executed to perform differnt aspects of the authentifcation. These
modules are stacken upon each other and assemble a control flow wich
can be configured in a wide range of variaties.
Each service that requires some kind of authetification has a PAM
configuration file in the directory /etc/pam.d, usually
named after the application performing this service. This
configuration file contains a list of modules reflecting the kind of
authentification needed for this service.
|
 |