CHAPTER 1

INTRODUCTION

Authentication is a process of verifying the identity of someone or something

to check whether they are what they claim to be. Typically a unique username and
password is provided to any user. To gain access to secure data, the user produces the
unique user name and password. Computers are tools. They provide services to people
and other computers (collectively we shall call these _users_ entities). In order to
provide convenient, reliable and individual service to different entities, it is common
for entities to be labelled. Having defined a label as referring to a some specific entity,
the label is used for the purpose of protecting and allocating data resources.
All modern operating systems have a notion of labelled entities and all modern
operating systems face a common problem: how to authenticate the association of a
predefined label with applicant

1.1 ENTITIES:
There are as many authentication methods as one might care to count. None of
them are perfect and none of them are invulnerable. In general, any given
authentication method becomes weaker over time. It is common then for new
authentication methods to be developed in response to newly discovered weaknesses
in the old authentication.

1.2 METHODS:
The problem with inventing new authentication methods is the fact that old
applications do not support them. This contributes to an inertia that discourages the
overhaul of weakly protected systems. Another problem is that individuals (people)
are frequently powerless to layer the protective authentication around their systems.
They are forced to rely on single (lowest common denominator) authentication
scheme seven in situations where this is far from appropriate.
PAM, as discussed in this document, is a generalization of the approach first
introduced in [1]. In short, it is a general framework of interfaces that abstract the
process of authentication.

1
 CHAPTER 2
OVERVIEW

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.
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 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.
There are a growing number of people who want to use remotely sensed data
and GIS data. What is needed is a large-scale processing and storage system that
provides high bandwidth Tlow cost. Scalable computing clusters, ranging from a
cluster of (homogeneous or heterogeneous) PCsor workstations, to SMPs, are rapidly
becoming the standard platforms for high-performance and large-scale computing. To
utilize the resources of a parallel computer, a problem had to be algorithmically
expressed as comprising a set of concurrently executing sub-problems or tasks. To
utilize the parallelism of cluster of SMPs, we present the basic programming
techniques byusing PVM to implement a message-passing program. The matrix
multiplication and parallel raytracing problems are illustrated and the experiments are
also demonstrated on our Linux SMPs cluster. The experimental results show that our
Linux/PVM cluster can achieve high speedups for applications. specific (strictly
between client and server) and orthogonal to the process of authentication.

2
 Figure 2.1 PAM FRAMEWORK

2.1 DEFINITIONS:

Here we pose the authentication problem as one of configuring defined Zinter

faces between two entities. Players in the authentication process. PAM reserves the
following words to specify unique entities in the complexity in authenticating users
increases due to the ubiquitous nature of the applications.
PAM and PAM-aware applications reduce the complexity and increases
flexibility for user authentication. With PAM, the system administrator can use the
same user database for every login process by different applications. Moreover, it is
possible to use more than one underlying authentication mechanisms. PAM has a well
defined set of API’s, and PAM-aware applications will not break if the system
administrator changes the underlying authentication scheme.

3
2.2 AUTHENTICATION PROCESS:

Applicant the entity (user) initiating an application for service

[PAM associates the PAM_RUSER _item_ with this requesting user]. Arbitratorthe
entity (user) under whose identity the service application is negotiated and with whose
authority service is granted.User the entity (user) whose identity is being
authenticated [PAM associates the PAM_USER _item_ with this identity]. Server the
application that provides service, or acts as an authenticated gateway to the requested
service.
This application is completely responsible for the server end of the transport
layer connecting the server to the client. PAM makes no assumptions about how data
is encapsulated for exchanges between the server and the client, only that full octet
sequences can be freely exchanged without corruption. Client application providing
the direct/primary interface to applicant. This application is completely responsible
for the client end of the transport layer connecting the server to the client. PAM
makes no assumptions about how data is encapsulated for exchanges between the
server and the client, only that full octet sequences can be freely exchanged without
corruption.
Module authentication binary that provides server-side support for some
(arbitrary) authentication method. Agent authentication binary that provides client-
side support for some (arbitrary) authentication method.
Here is a diagram to help orient the reader:

+-------+

+--------+

. . . . .| agent |

.| module |

+-------+

.+--------+

4
|

.|

V|

+---------+ +-------+

. +------+

| |libpamc|

. |libpam|

| +-------+

. +------+

|applicant|

.|

| +--------+

+----------+

|---| client |-----------| server |

+---------+ +--------+

+----------+

5
 Solid lines connecting the boxes represent two-way interaction. The dotted-
directed lines indicate an optional connection between the plug in module (agent) and
the server (applicant). In the case of the module, this represents the module invoking
the 'conversation' callback function provided to lib pam by the server application
when it inititializes the lib pam library. In the case of the agent, this may be some out-
of-PAM API interaction (for example directly displaying a dialog box under X).
2.3 DEFINED DATA TYPES:

In this draft, we define two composite data types, the text string and the
binary prompt. They are the data types used to communicate authentication requests
and responses.

This application is completely responsible for the server end of the transport
layer connecting the server to the client. PAM makes no assumptions about how data
is encapsulated for exchanges between the server and the client, only that full octet
sequences can be freely exchanged without corruption. Client application providing
the direct/primary interface to applicant. This application is completely responsible
for the client end of the transport layer connecting the server to the client. PAM
makes no assumptions about how data is encapsulated for exchanges between the
server and the client, only that full octet sequences can be freely exchanged without
corruption.

6
 CHAPTER 3
PAM MANAGEMENT SERVICES

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.

3.1 AUTH:

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

3.2 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.

3.3 PASSWORD:

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

3.4 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.

7
3.5 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.

3.6 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.

3.7 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.

3.8 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.

3.9 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.

8
3.10 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.

The module provides both authentication and session services. The

authentication service allows users who have passphrase-protected SSH secret keys in
their ~/.ssh directory to authenticate themselves by typing their passphrase. The
session service starts ssh-agent and preloads it with the keys that were decrypted in
the authentication phase. This feature is particularly useful for local logins, whether in
X (using or another PAM-aware X login manager) or at the console.

This module implements what is fundamentally a password authentication

scheme. Care should be taken to only use this module over a secure session (secure
TTY, encrypted session, etc.), otherwise the user's SSH passphrase could be
compromised.Additional consideration should be given to the use of. Users often
assume that file permissions are sufficient to protect their SSH keys, and thus use
weak or no passphrases. Since the system administrator has no effective means of
enforcing SSH passphrase quality, this has the potential to expose the system to
security risks.

The module implements traditional UNIX® password authentication, using

under FreeBSD or ) under NetBSD to obtain the target account's password and
compare it with the one provided by the applicant. It also provides account
management services (enforcing account and password expiration times) and
password-changing services. This is probably the single most useful module, as the
great majority of admins will want to maintain historical behaviour for at least some
services.

9
 CHAPTER 4
BASIC PAM MODULES
4.1 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/password.
4.2 ACCOUNT:

Establishes 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/password and /etc/shadow files.
Arguments: audit, debug.
4.3 AUTH:

This component of the module checks the user’s password against the
password databases. Configuration for this component is done in /etc/ns switch. conf.
An additional binary, unix_chkpwd, is used to allow the component to read protected
databases without requiring the whole module to be set uid root. Arguments: audit,
debug, no delay, null ok, try_ first_ pass, use _first_ pass.

4.4 PASSWORD:

This component changes the user’s password. The module pam_cracklib.so

can be stacked with this component to check password security. Arguments: audit,
igcrypt, debug, md5, nis, not_set_pass, nullok, remember, try_first_pass, use_authtok,
and use_first_pass.
4.5 SESSION:

This 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.

10
4.5 AUDIT:

A more extensive form of debug o big crypt 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.

No delay – 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.

Null ok – By default, if the official password is blank, the authentication fails.

This argument overrides the default.

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.

11
NETWORK PAM MODEL DIAGRAM:

Figure 4.6 Network Pam Model Diagram

12
 CHAPTER 5
PAM CONNECTIVITY

5.1 M_RUSER and a PAM_RHOST:

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).
5.2 USERS:

XXX,YYY,… – instead of ftp or anonymous, provide anonymous login to

thecomma 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”.
5.3 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 useto 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. so This
module can be plugged into the password stack of a given application to provide
some plug- in strength-checking for passwords.

PAM employs run-time pluggable modules to provide authentication

relatedservices. These modules are broken into four different types based on
theirfunction: authentication, account management, session management andpassword
management.The authentication modules provide authentication for the users and
allows forcredentials to be set, refreshed or destroyed. These modules allow for the
userto be identified.

13
 The account modules checks for password aging, account expiration and
accesshour restrictions. Once the user is identified using the authentication
modules,the account modules will determine if the user can be given access.
The session modules primarily manage the opening and closing of
anauthentication session. They can log activity or can provide for clean-up after
the session is over.The password modules allow for changes to the password and the
password-related attributes.
PAM allows for authentication by multiple methods through stacking. When a
user is authenticated through PAM, multiple methods can be selected to fully identify
the user. Depending on the configuration, the user can be prompted for passwords for
each authentication method. Therefore, the user will not need to remember to execute
another command to get fully authenticated. The order that the methods are used is
determined through the configuration file,
/etc/pam.conf.

Stacking can require that a user would need to remember several

passwords.Password-mapping, if supported by the underlying module, allows for
theprimary password to be used to decrypt the other passwords, so that the userwill
not need to remember or enter multiple passwords. The other optionwould be to
synchronize the password across each authentication mechanism.
Note that this may increase the security risk, because the security of
eachmechanism would be limited by the least secure password method used in
thestack.

5.4 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

14
•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:

15
 CHAPTER 6
PAM ADMINISTRATION

The Pluggable Authentication Module(PAM) framework allows for new

authentication technologies to be “plugged-in” without changing command login, ftp,
telnet, and so on. It can be used to integrate UNIX login with other security
mechanisms like DCE or Kerberos. Mechanisms for account, session and password
management can also be “plugged-in” using this framework.
6.1 How Does PAM Work?

The figure below illustrates the relationship between the applications,

thelibrary and the modules. The applications (ftp, telnet and login) use thePAM
library to access the appropriate module. The pam.conf file defines whichmodules are
to be used with each application. Responses from the modules arepassed back through
the library to the application.

Figure 6.1 PAM Cotrolling Service

16
 CHAPTER 7
PAM SOFTWARE

3The PAM software consists of a library, several modules and configuration

file. The current release also includes new versions of several commands whichuse
the PAM interfaces.

7.1 PAM LIBRARY:

Tshe PAM library, /usr/lib/libpam, provides the framework to load the

appropriate modules and manage stacking. It provides a generic structure forall of the
modules to plug into.

7.2 PAM MODULES:

Each module provides the implementation of a specific mechanism. More

than one module type (auth, account, session or password) may be associated with
each module, but each module needs to manage at least one module type. Here is a
description of some of the modules.

Figure 7.1 pam module

17
The pam_unix module

/usr/lib/security/pam_unix.so.1, provides support for authentication,

account management, session management and password management. Any of the
four module type definitions can be used with this module (see the pam_unix(5) man
page). It uses UNIX passwords for authentication. In Solaris, this is controlled
through /etc/nsswitch.conf.
The dial_auth module

/usr/lib/security/pam_dial_auth.so.1, can only be used for authentication

(see the pam_dial_auth(5) man page). It uses data stored in the /etc/dialups and
/etc/d_passwd files for authentication. This is mainly used by login.
The rhosts_auth module

/usr/lib/security/pam_rhosts_auth.so.1, can also only be used for

authentication (see the pam_rhosts_auth(5) man page). It uses data stored in the
~/.rhosts and /etc/host.equiv files through ruserok(). This is mainly used by rlogin and
rsh.
The pam_dce module

/usr/lib/security/pam_dce.so.1, provides support for authentication, account

management, and password management. Any of these three module type definitions
can be used with this module (see the pam_dce(5) man page). The module uses DCE
Registry for authentication.

18
 CHAPTER 8
CONCLUSOINS

With the above we are able to do authenticated smtp using standard out of the box
exim and the standard pam modules that come with linux. So no need for sassl authd
or pam_exim or anything else, it all just works. Hope this is cluefull to those of you
trying to do the same.
8.1 POINTS FOR CONSIDERATION

 I found this helpful, but suggest that other readers should consider two points
re /etc/pam.d/exim file above:
 Is null_ok right for your system (Do you want to allow accounts with no
password to relay mail)?

19
 CHAPTER-9
LIST OF REFERENCES
 http://www.kernel.org/pub/linux/libs/pam/
 Making Login Services Independent of Authentication Technologies. Vipin
Samar and Charlie Lai. Sun Microsystems.
 X/Open Single Sign-on Preliminary Specification.
 Pluggable Authentication Modules. Andrew G. Morgan.

20