2. The Authentication Problem
â Traditionally, UNIX authentication is done by comparing the (encrypted) password
for users in the password file /etc/shadow.
â Each program that requires authentication implements its own authentication
mechanisms.
â Authentication mechanism becomes more visible when you add various applications
that are doing some sort of authentication.
â Like: Logging from a graphical user interface using display managers.
â Services like : FTP, TELNET, IMAP, SSH.
â As a system administrator you will end up spending a lot of time maintaining many
user database besides /etc/passwd.
3. Need for PAM
â With PAM, the system administrator can use the same user database for every login
process of your system.
â It is possible to use more than one underlying authentication mechanisms (back end)
controlled by PAM and transparent to the users.
â PAM-aware applications will not break if the system administrator changes the
underlying authentication configuration.
â Using PAM for authentication requires much less programming than developing a
complete set of authentication functions.
4. History of PAM
â In 1995, developers from Sun Microsystems implement a generic
framework for Solaris.
â In Aug 1997, when Solairs 2.6 was released PAM was an integrated
component of the operating system.
â In Feb 1997, the Linux-PAM project began
â Now most GNU/Linux distributions today are using PAM.
4
5. Theory of Operation
â The theory of operations is independent of the operating system and PAM
implementation.
â In order to configure PAM successfully, you need to have all the components
working together correctly.
â PAM framework is complex and not forgiving when it comes to errors.
6. PAM File System Layout
/ lib
libpam.so.0
security
pam_unix.so
pam_deny.so
etc
pam.conf
pam.d
login
ssh
other
security
access.conf
usr
pam_mount.conf
include
security
pam_modules.h
pam_appl.h
pam_misc.h
7. PAM File System Layout (Cont.)
â The PAM-aware applications are linked against the PAM library, which
located in /lib/ directory with the name libpam-X.so.0
â Configuration of PAM can be done in two ways
âą Put everything in one single file /etc/pam.conf
âą Or split the configuration by service in the directory /etc/pam.d
â Some PAM modules required configurations files beside the PAM
configuration to operate.
8. PAM Framework
â PAM relies on dynamically loaded modules.
â A module can provide mechanisms to authenticate user information stored in a
particular back end.
â A PAM service module is a shared library that provides authentication and
other security services to applications such as login, or telnet.
â The four types of PAM services are:
âą Authentication service modules.
âą Account management modules.
âą Session management modules.
âą Password management modules.
10. Management Groups
â Each Service can use PAM in four different stages of the Authentication
process.
â These stages are called management groups.
â A module provides the functionality for one or more management Groups.
â You can think about it as a different module for each group.
11. Management Groups (Cont.)
The Auth Group
â Provides two functions:
âą First the user can be validated
âą Second, credentials are granted by the auth management group
12. Management Groups (Cont.)
The Account Group
â The access to a service is controlled by the account management group.
â You might only be allowed to use a service
âą A number of times per week.
âą In certain periods of the day.
âą Or, if your account is not yet expired.
13. Management Groups (Cont.)
The Session Group
â The environment for a given service is built up by the session management group.
â When you stop using a service , the session groups tears down the environment.
â When creating the environment the data required for proper operation will be
loaded.
14. Management Groups (Cont.)
The Password Group
â It is only used when a user wishes to update the password.
â With PAM you separate passwords changing applications from the back-end
storage.
15. Stacking
â For each management groups you can define a set or a stack of modules,
which are used in turn.
â The order of calling is determined by the order in the configuration (service)
file.
â Changing the order in the stack might have great impact on the functionality.
auth [success=1 default=ignore] pam_unix.so nullok_secure
auth [success=1 default=ignore] pam_unix.so nullok_secure
auth required pam_permit.so
16. Control Flags
â A module can either return success or failure.
â Some answers are more important than others.
â The control flags can change the flow and how decisions are made.
17. Control Flags (Cont.)
Requisite
â If is the strongest of the flags.
â If a module is flagged as requisite, and it fails, PAM will return to the calling
applications instantly and report the failure.
18. Control Flags (Cont.)
Required
â The return code for a required module is stored.
â In the case of failure, execution is not stopped but continues to the next module.
â When the stack of modules has been executed, and at least one required module
has failed, PAM will return failure to the calling application.
19. Control Flags (Cont.)
Sufficient
â A sufficient module can actually be quite strong.
â The processing of the stack is stopped if a sufficient module returns OK, if
no previous required module has failed.
â If there are required modules after the sufficient modules, these modules
are not called.
20. Control Flags (Cont.)
Optional
â A failure does not alter the execution of the stack as in the case of the requisite
flag.
â The return code is ignored, and neither failure nor success is taken into account
21. Developing with PAM
PAM Application
Application PAM runtime Module
pam_start
Data structure
initialized
pam_handle
Checking user
pam_auth
pam_unix
Conversation
function
pam_end
Data structure
destroyed
time
22. References
â The Definitive Guide to PAM for Linux SysAdmins and C Developers.
â The Linux-PAM Guides http://www.kernel.org/pub/linux/libs/pam/
â Linux CBT PAM.
â PAM manual pages.
23. Session End
Thank You
Ahmed Madkour
ahm.madkour@gmail.com