Pluggable Authentication Module

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    Favorites, Groups & Events

    Pluggable Authentication Module - Presentation Transcript

    1. Pluggable Authentication Module Ahmed Madkour
    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.
    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. 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
    SlideShare Zeitgeist 2009

    + SinarSheblSinarShebl Nominate

    custom

    175 views, 0 favs, 0 embeds more stats

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 175
      • 175 on SlideShare
      • 0 from embeds
    • Comments 0
    • Favorites 0
    • Downloads 2
    Most viewed embeds

    more

    All embeds

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories