Here, we collect together some descriptions of the various modules available for Linux-PAM. In general these modules should be freely available. Where this is not the case, it will be indicated.
Also please note the comments contained in the section on text conventions above when copying the examples listed below.
pam_chroot
Bruce Campbell <brucec@humbug.org.au>
Author; proposed on 20/11/96 - email for status
account; session; authentication
Unwritten.
Expects localhost.
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.
Need more info here.
Need more info here.
Need more info here.
Arguments and logging levels for the PAM version are being worked on.
Do provide a reasonable list of programs - just tossing 'cat', 'ls', 'rm', 'cp' and 'ed' in there is a bit...
Don't take it to extremes (eg, you can set up a separate environment for each user, but its a big waste of your disk space.)
pam_cracklib
Cristian Gafton <gafton@sorosis.ro>
Author.
password
Requires the system library libcrack and a system dictionary:
/usr/lib/cracklib_dict.
This module can be plugged into the password stack of a given
application to provide some plug-in strength-checking for passwords.
(XXX - note this does not necessarily work with the pam_unix module,
although it is known to work with the pam_pwdb replacement for the
unix module -- see example and pam_pwdb write up for more
information).
debug; type=XXX; retry=N
The action of this module is to prompt the user for a password and check its strength against a system dictionary and a set of rules for identifying poor choices.
The default action is to prompt for a single password, check its strength and then, if it is considered strong, prompt for the password a second time (to verify that it was typed correctly on the first occasion). All being well, the password is passed on to subsequent modules to be installed as the new authentication token.
The default action may be modified in a number of ways using the arguments recognized by the module:
debug -
this option makes the module write information to syslog(3) indicating
the behavior of the module (this option does not write password
information to the log file).
type=XXX -
the default action is for the module to use the following prompts when
requesting passwords: ``New UNIX password: '' and ``Retype UNIX
password: ''. Using this option you can replace the word UNIX with
XXX.
retry=N -
the default number of times this module will request a new password
(for strength-checking) from the user is 1. Using this argument this
can be increased to N.
(At the time of writing, this module can only be stacked before the
pam_pwdb module. Cracklib strength checking may be compiled by
default into the pam_unix module.)
For an example of the use of this module, we show how it may be
stacked with the password component of pam_pwdb:
#
# These lines stack two password type modules. In this example the user
# is given 3 opportunities to enter a strong password. The
# "use_authtok" argument ensures that the pam_pwdb module does not
# prompt for a password, but instead uses the one provided by
# pam_cracklib.
#
passwd password required /usr/lib/security/pam_cracklib.so retry=3
passwd password required /usr/lib/security/pam_pwdb.so use_authtok
pam_deny
Andrew G. Morgan <morgan@parc.power.net>
current Linux-PAM maintainer
account; authentication; password; session
clean.
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.
This component does nothing other than return a failure. The
failure type is PAM_ACCT_EXPIRED.
Stacking this module with type account will prevent the user from
gaining access to the system via applications that refer to
Linux-PAM's account management function pam_acct_mgmt().
The following example would make it impossible to login:
#
# add this line to your other login entries to disable all accounts
#
login account required /usr/lib/security/pam_deny.so
This component does nothing other than return a failure. The failure
type is PAM_AUTH_ERR in the case that pam_authenticate() is
called (when the application tries to authenticate the user), and is
PAM_CRED_UNAVAIL when the application calls pam_setcred()
(to establish and set the credentials of the user -- it is unlikely
that this function will ever be called in practice).
To deny access to default applications with this component of the
pam_deny module, you might include the following line in your
Linux-PAM configuration file:
#
# add this line to your existing OTHER entries to prevent authentication
# succeeding with default applications.
#
OTHER auth required /usr/lib/security/pam_deny.so
This component of the module denies the user the opportunity to change
their password. It always responds with PAM_AUTHTOK_ERR when
invoked.
This module should be used to prevent an application from updating the
applicant user's password. For example, to prevent login from
automatically prompting for a new password when the old one has
expired you should include the following line in your configuration
file:
#
# add this line to your other login entries to prevent the login
# application from being able to change the user's password.
#
login password required /usr/lib/security/pam_deny.so
This aspect of the module prevents an application from starting a session on the host computer.
Together with another session module, that displays a message of the
day perhaps (XXX - such a module needs to be written),
this module can be used to block a user from starting a shell. Given
the presence of a pam_motd module, we might use the following
entries in the configuration file to inform the user it is system
time:
#
# An example to see how to configure login to refuse the user a
# session (politely)
#
login session required /usr/lib/security/pam_motd.so \
file="/etc/system_time"
login session required /usr/lib/security/pam_deny.so
pam_filter
Andrew G. Morgan <morgan@parc.power.net>
Author.
account; authentication; password; session
Not yet.
This module compiles cleanly on Linux based systems.
To function it requires filters to be installed on the system.
This module was written to offer a plug-in alternative to programs like ttysnoop (XXX - need a reference). Since writing a filter that performs this function has not occurred, it is currently only a toy. The single filter provided with the module simply transposes upper and lower case letters in the input and output streams. (This can be very annoying and is not kind to termcap based editors).
debug; new_term; non_term; runX
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 the that filter is to be run. To explain 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).
At the time of writing there is little real use to be made of this module. For fun you might try adding the following line to your login's configuration entries
#
# An example to see how to configure login to transpose upper and
# lower case letters once the user has logged in(!)
#
login session required /usr/lib/security/pam_filter.so \
run1 /usr/sbin/pam_filter/upperLOWER
pam_ftp.so
Andrew G. Morgan <morgan@parc.power.net>
Author.
authentication
prompts for email address of user; easily spoofed (XXX - needs work)
The purpose of this module is to provide a pluggable anonymous ftp mode of access.
debug;
users=XXX,YYY,...;
ignore
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).
An example of the use of this module is provided in the configuration file section above . With care, this module could be used to provide new/temporary account anonymous login.
pam_group
Andrew G. Morgan <morgan@parc.power.net>
Author.
authentication
Sensitive to setgid status of file-systems accessible to users.
Requires an /etc/security/group.conf file. Can be compiled
with or without libpwdb.
Only through correctly set PAM_TTY item.
This module provides group-settings based on the user's name and the terminal they are requesting a given service from. It takes note of the time of day.
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.
For this module to function correctly there must be a correctly
formatted /etc/security/groups.conf file present. The format
of this file is as follows. Group memberships are given based on the
service application satisfying any combination of lines in the
configuration file. Each line (barring comments which are preceded by
`#' marks) has the following
syntax:
services ; ttys ; users ; times ; groups
pam_time
configuration file; /etc/security/pam_time.conf, and the last
field, the groups field, is a comma (or space) separated list of
the text-names of a selection of groups. If the users application for
service satisfies the first four fields, the user is granted membership
of the listed groups.
As stated in above this module's usefulness relies on the file-systems accessible to the user. The point being that once granted the membership of a group, the user may attempt to create a setgid binary with a restricted group ownership. Later, when the user is not given membership to this group, they can recover group membership with the precompiled binary. The reason that the file-systems that the user has access to are so significant, is the fact that when a system is mounted nosuid the user is unable to create or execute such a binary file. For this module to provide any level of security, all file-systems that the user has write access to should be mounted nosuid.
The pam_group module fuctions in parallel with the
/etc/group file. If the user is granted any groups based on
the behavior of this module, they are granted in addition to
those entries /etc/group (or equivalent).
pam_krb4
Derrick J. Brashear <shadow@dementia.org>
Author.
authentication; password; session
uses API
libraries - libkrb, libdes, libcom_err, libkadm;
and a set of Kerberos include files.
Gets Kerberos ticket granting ticket via a Kerberos key distribution center reached via the network.
This module provides an interface for doing Kerberos verification of a user's password, getting the user a Kerberos ticket granting ticket for use with the Kerberos ticket granting service, destroying the user's tickets at logout time, and changing a Kerberos password.
This component of the module currently sets the user's KRBTKFILE
environment variable (although there is currently no way to export
this), as well as deleting the user's ticket file upon logout (until
PAM_CRED_DELETE is supported by login).
This part of the module won't be terribly useful until we can change
the environment from within a Linux-PAM module.
use_first_pass; try_first_pass
This component of the module changes a user's Kerberos password by first getting and using the user's old password to get a session key for the password changing service, then sending a new password to that service.
This should only be used with a real Kerberos v4 kadmind. It
cannot be used with an AFS kaserver unless special provisions are
made. Contact the module author for more information.
use_first_pass; try_first_pass
This component of the module verifies a user's Kerberos password by requesting a ticket granting ticket from the Kerberos server and optionally using it to attempt to retrieve the local computer's host key and verifying using the key file on the local machine if one exists.
It also writes out a ticket file for the user to use later, and
deletes the ticket file upon logout (not until PAM_CRED_DELETE
is called from login).
This module can be used with a real Kerberos server using MIT v4 Kerberos keys. The module or the system Kerberos libraries may be modified to support AFS style Kerberos keys. Currently this is not supported to avoid cryptography constraints.
pam_limits
Cristian Gafton <gafton@sorosis.ro>
Thanks are also due to Elliot Lee <sopwith@redhat.com>
for his comments on improving this module.
Cristian Gafton - 1996/11/20
session
requires an /etc/security/limits.conf file and kernel support
for resource limits. Also uses the library, libpwdb.
This module, through the Linux-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 discussed below.
debug; conf=/path/to/file.conf
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.
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. No limits
are imposed on uid=0 accounts.
Each line of the configuration file describes a limit for a user in the form:
<domain> <type> <item> <value>
The fields listed above should be filled as follows...
<domain> can be:
@group syntax*, for default entry<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.
<item> can be 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 filesrss - max resident set size (KB)stack - max stack size (KB)cpu - max CPU time (MIN)nproc - max number of processesas - address space limitmaxlogins - max number of logins for this user.To completely disable limits for a user (or a group), a single dash
(-) will do (Example: ``bin -'', ``@admin -''). 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 pam_limits module does its best to report configuration
problems found in its configuration file via syslog(3).
The following is an example configuration file:
# EXAMPLE /etc/security/limits.conf file:
# =======================================
# <domain> <type> <item> <value>
* soft core 0
* hard rss 10000
@student hard nproc 20
@faculty soft nproc 20
@faculty hard nproc 50
ftp hard nproc 0
@student - maxlogins 4
soft and hard limits for the same resource
(see @faculty) -- this establishes the default and permitted
extreme level of resources that the user can can obtain in a
given service-session.
For the services that need resources limits (login for example) put a
the following line in /etc/pam.conf as the last line for that
service (usually after the pam_unix session line:
#
# Resource limits imposed on login sessions via pam_limits
#
login session required /usr/lib/security/pam_limits.so
pam_listfile
Elliot Lee <sopwith@cuc.edu>
Red Hat Software:
Michael K. Johnson <johnsonm@redhat.com> 1996/11/18
(if unavailable, contact Elliot Lee <sopwith@cuc.edu>).
authentication
clean
The list-file module provides a way to deny or allow services based on an arbitrary file.
onerr=succeed|fail;
sense=allow|deny;
file=filename;
item=user|tty|rhost|ruser|group|shell
apply=user|@group
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.conf:
#
# deny ftp-access to users listed in the /etc/ftpusers file
#
ftp auth required /usr/lib/security/pam_listfile.so \
onerr=succeed item=user sense=deny file=/etc/ftpusers
/etc/ftpusers file are
(counterintuitively) not allowed access to the ftp service.
To allow login access only for certain users, you can use an pam.conf entry like this:
#
# permit login to users listed in /etc/loginusers
#
login auth required /usr/lib/security/pam_listfile.so \
onerr=fail item=user sense=allow file=/etc/loginusers
For this example to work, all users who are allowed to use the login
service should be listed in the file /etc/loginusers. Unless
you are explicitly trying to lock out root, make sure that when you do
this, you leave a way for root to log in, either by listing root in
/etc/loginusers, or by listing a user who is able to su
to the root account.
pam_mail
Andrew G. Morgan <morgan@parc.power.net>
Author
session
Default mail directory /var/spool/mail/
This module looks at the user's mail directory and indicates whether the user has any mail in it.
debug; dir=direcory-name; nopen; close;
noenv
This module provides the ``you have new mail'' service to the user. It
can be plugged into any application that has session 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.
nopen
- instruct the module to not print any mail information when the
user's session is opened. 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 end
of the session.
noenv
- do not set the MAIL environment variable.
This module can be used to indicate that the user has new mail when
they login to the system. Here is a sample entry for your
/etc/pam.conf file:
#
# do we have any mail?
#
login session optional /usr/lib/security/pam_mail.so
Note, some applications may perform this function themselves. In such cases, this module is not necessary.
pam_nologin
Written by Michael K. Johnson <johnsonm@redhat.com>
(based on code taken from a module written by Andrew G. Morgan
<morgan@parc.power.net>).
Michael K. Johnson <johnsonm@redhat.com>
authentication
1 warning about dropping const
Provides standard Unix nologin authentication.
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.
pam_permit
Andrew G. Morgan, <morgan@parc.power.net>
Linux-PAM maintainer.
account; authentication; password; session
VERY LOW. Use with extreme caution.
Clean.
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.
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 she might use the following configuration file entry for login:
#
# add this line to your other login entries to disable account
# management, but continue to permit users to log in...
#
login account required /usr/lib/security/pam_permit.so
pam_pwdb
Cristian Gafton <gafton@sorosis.ro>
and Andrew G. Morgan <morgan@parc.power.net>
Authors.
account; authentication; password; session
Requires properly configured libpwdb
This module is a pluggable replacement for the pam_unix_..
modules. It uses the generic interface of the Password Database
library
http://parc.power.net/morgan/libpwdb/index.html
.
debug
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.
In its accounting mode, this module can be inserted as follows:
#
# Ensure users account and password are still active
#
login account required /usr/lib/secrity/pam_pwdb.so
debug;
use_first_pass;
try_first_pass;
nullok
The debug argument makes the authentication functions of this
module syslog(3) more information on its actions.
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.
When given the argument try_first_pass, before prompting the user
for their password, the module first tries the previous stacked
auth-module's password in case that satisfies this module as
well. The argument use_first_pass forces the module to use such a
recalled password and will never prompt the user - if no password is
available or the password is not appropriate, the user will be denied
access.
Remaining arguments, supported by the other functions of this module,
are silently ignored. Other arguments are logged as errors through
syslog(3).
The correct functionality of this module is dictated by having an
appropriate /etc/pwdb.conf file, the user
databases specified there dictate the source of the authenticated
user's record.
debug; nullok; not_set_pass; use_authtok;
try_first_pass; use_first_pass; md5; shadow;
radius
This part of the pam_pwdb module performs the task of updating
the user's password. Thanks to the flexibility of libpwdb this
module is able to move the user's password from one database to
another, perhaps securing the user's database entry in a dynamic
manner (this is very ALPHA code at the moment!) - this is the
purpose of the shadow and radius arguments.
In the case of conventional unix databases (which store the password
encrypted) the md5 argument is used to do the encryption with the
MD5 function as opposed to the conventional crypt(3) call.
The nullok module is used to permit the changing of a password
from an empty one. Without this argument, empty passwords are
treated as account-locking ones.
The argument use_first_pass is used to lock the choice of old and
new passwords to that dictated by the previously stacked password
module. The try_first_pass argument is used to avoid the user
having to re-enter an old password when pam_pwdb follows a module
that possibly shared the user's old password - if this old password is
not correct the user will be prompted for the correct one. The
argument use_authtok is used to force this module to set the
new password to the one provided by the previously stacked
password module (this is used in an example of the stacking of
the Cracklib module documented above).
The not_set_pass argument is used to inform the module that it is
not to pay attention to/make available the old or new passwords from/to
other (stacked) password modules.
The debug argument makes the password functions of this module
syslog(3) more information on its actions. Other arguments may be
logged as erroneous to syslog(3).
An example of the stacking of this module with respect to the
pluggable password checking module, pam_cracklib, is given in
that modules section above.
No arguments are recognized by this module component. 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 use of the session modules is straightforward:
#
# pwdb - unix like session opening and closing
#
login session required /usr/lib/security/pam_pwdb.so
pam_radius
Cristian Gafton <gafton@sorosis.ro>
Author.
session
This module does not deal with passwords
gcc reports 1 warning when compiling /usr/include/rpc/clnt.h.
Hey, is not my fault !
requires /etc/security/radius.conf - configuration file which holds
the secret shared with the RADIUS server.
yes; this is a network module (independent of application).
This module is intended to provide the session service for users autheticated with a RADIUS server. At the present stage, the only option supported is the use of the RADIUS server as an accounting server.
debug - verbose logging to syslog(3).
This module is intended to provide the session service for users autheticated with a RADIUS server. At the present stage, the only option supported is the use of the RADIUS server as an accounting server.
(There are few things which needs to be cleared out first in the PAM project until one will be able to use this module and expect it to magically start pppd in response to a RADIUS server command to use PPP for this user, or to initiate a telnet connection to another host, or to hang and call back the user using parameters provided in the RADIUS server response. Most of these things are better suited for the radius login application. I hope to make available Real Soon (tm) patches for the login apps to make it work this way.)
When opening a session, this module sends an ``Accounting-Start'' message to the RADIUS server, which will log/update/whatever a database for this user. On close, an ``Accounting-Stop'' message is sent to the RADIUS server.
This module has no other prerequisites for making it work. One can install a RADIUS server just for fun and use it as a centralized accounting server and forget about wtmp/last/sac etc. .
For the services that need this module (login for example) put
the following line in /etc/pam.conf as the last line for that
service (usually after the pam_unix session line):
login session required /lib/security/pam_radius.so
login for each service you are using this module.
This module expects to find a RADIUS client configuration installed.
Well, it sounds complicated, but all you need to do is to update your
root-read-only /etc/security/radius.conf file.
Remember, this file MUST be readable only by root!
pam_rhosts_auth
Al Longyear <longyear@netcom.com>
authentication
Clean.
Standard inet_addr(), gethostbyname() function calls.
This module performs the standard network authentication for services, as used by traditional implementations of rlogin and rsh etc.
no_hosts_equiv; no_rhosts; debug; no_warn
The authentication mechanism of this module is based on the contents
of two files; /etc/hosts.equiv (or _PATH_HEQUIV in
#include <netdb.h>) 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.
Note, the name "root" is hard-wired into the program (XXX - this
should be reconfigurable with a configuration option). Caution
should be used in the case that the local superuser goes by another
name. In the case of root-access, the /etc/host.equiv
file is ignored. 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.
no_rhosts -
ignore the contents of all user's personal configuration file
~/.rhosts.
To allow users to login from trusted remote machines, you should try
adding the following line to your /etc/pam.conf file
before the line that would otherwise prompt the user for a
password:
#
# No passwords required for users from hosts listed above.
#
login auth sufficient /usr/lib/security/pam_rhosts_auth.so no_rhosts
/etc/host.equiv file, by replacing sufficient in the
above example with required.
pam_rootok
Andrew G. Morgan <morgan@parc.power.net>
Linux-PAM maintainer
authentication
Clean.
This module is for use in situations where the superuser wishes to gain access to a service without having to enter a password.
debug
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.
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 Linux-PAM
the following pair of lines are needed for the corresponding entry in
the configuration file:
#
# su authentication. Root is granted access by default.
#
su auth sufficient /usr/lib/security/pam_rootok.so
su auth required /usr/lib/security/pam_unix_auth.so
Note. For programs that are run by the superuser (or started when the system boots) this module should not be used to authenticate users.
pam_securetty
Elliot Lee <sopwith@cuc.edu>
Red Hat Software:
currently Michael K. Johnson <johnsonm@redhat.com>
(if unavailable, contact Elliot Lee <sopwith@cuc.edu>).
authentication
/etc/securetty file
Requires the application to fill in the PAM_TTY item
correctly in order to act meaningfully.
Provides standard Unix securetty checking.
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_time
Andrew G. Morgan <morgan@parc.power.net>
Author
account
Requires a configuration file /etc/security/time.conf
Through the PAM_TTY item only
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/pam.conf. Each rule has the following
form,
services;ttys;users;times
#'. It contains four fields separated
with semicolons, `;'. The fields are as follows:
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.
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 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 finsish 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'.
The use of this module is initiated with an entry in the Linux-PAM configuration file of the following type:
#
# apply pam_time accounting to login requests
#
login account required /usr/lib/security/pam_time.so
Some examples of rules that can be placed in the
/etc/security/time.conf configuration file are the following:
login ; tty* & ; !ttyp* ; !root ; !Al0000-2400all users except for root are denied access to console-login at
all times.
games ; * ; !waster ; Wd0000-2400 | Wk1800-0800games (configured to use Linux-PAM) are only to be accessed out of
working hours. This rule does not apply to the user waster.
Note, currently there is no daemon enforcing the end of a session. This needs to be remedied.
Poorly formatted rules are logged as errors using syslog(3).
pam_warn
Andrew G. Morgan <morgan@parc.power.net>
Author.
authentication; password
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.
an example is provided in the configuration file section above .
pam_wheel
Cristian Gafton <gafton@sorosis.ro>
Author.
authentication
Requires libpwdb.
Only permit root access to members of the wheel (gid=0) group.
debug;
use_uid;
trust;
deny;
group=XXXX
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 restrict access to superuser status to the members of the
wheel group, use the following entries in your configuration
file:
#
# root gains access by default (rootok), only wheel members can become
# root (wheel) but Unix authenticate non-root applicants.
#
su auth sufficient /usr/lib/security/pam_rootok.so
su auth required /usr/lib/security/pam_wheel.so
su auth required /usr/lib/security/pam_unix_auth.so
Next Chapter, Previous Chapter
Table of contents of this chapter, General table of contents
Top of the document, Beginning of this Chapter