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