Pluggable Authentication Module

1,793 views

Published on

Published in: Technology, Art & Photos
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,793
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
50
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Pluggable Authentication Module

  1. 1. Pluggable Authentication Module Ahmed Madkour
  2. 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. 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. 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. 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. 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. 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. 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.
  9. 9. PAM Framework (Cont.) Application PAM Services Modules Login PAM PAM Lib API /lib/libpam.so Telnet pam_ pam_ pam_ unix.so ldap.so mount.so Pam. pam.d conf Other /etc/ Appl security/ /etc/ LDAP pam_ passwd server mount. conf
  10. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 23. Session End Thank You Ahmed Madkour ahm.madkour@gmail.com

×