Plugged Authentication Module

1. Plugged Authentication Module Enijmax 4/23/2004 8/17/2004 updated

2. PAM Design Goals • The system admin should be able to choose the default authentication mechanism for the machine. The range from a simple password to complex smart card system. • It should be possible to configure the user authentication mechanism on a per application basis. • The framework should support the display requirements of the applications.[顯示密碼提示的需求] • It should be possible to configure multiple authentication protocols for each of those applications. • The system administrator should be able to stack multiple user authentication mechanisms such that the user is authenticated with all authentication protocols without retyping the password. • The architecture should allow for multiple passwords if necessary to achieve higher security for users with specific security requirements. • The system-entry services should not be required to change when the underlying mechanism changes. • For backward-compatibility reasons, the PAM API should support the authentication requirements of the current system-entry services.

3. PAM Architecture 程式流動的方向

4. Four Basic functions • Authentication • PAM uses to know how to authenticate a user to the system’s authentication method. The first is to determine that the user is who they say they are, by passwords or other token. Second the module sets up the credentials for the user, such as user id. • Account • It verifies the accounts availability. • Session • It handles what is needed to set-up and tear-down a session. Including logging and setting up any mounts. • Password • Change the authentication token (ex : password) associated with an account.

5. Four Building Block • PAM aware applications/services • PAM aware application will have a call to the PAM library and then in turn the libraries/modules do the work of authentication according to the PAM configuration file specification. • PAM libraries • The PAM library modules are at the heart of what makes PAM work. The PAM library modules are the dynamically linked functions that are called to do the PAM configured tasks. Different modules are developed to work with one or more of the four basic tasks. • PAM configuration file or files • See the next page. • Information data files or databases that a library may look for or need to access. • Pam_unix.so use the /etc/passwd and /etc/shadow files or a password database. • Pam_pwdb.so module is used with the account action to write accounting information to syslog and update /etc/utmp and /etc/wtmp.

6. Configuration file • Format: • Application-Name, Type, control-flag, module-path, module-arguments [/etc/pam.conf] • Type, Control-flag, module-path, module-arguments [/etc/pam.d/*] • Type • Auth • Account • Session • Password • Control Flag • Required • Requisite • Sufficient • Optional

7. Configuration file (Cont.) • Module-path • The module path is the actual path to the library module you want to use for a specific task type. • Not all library modules can be used with all the task types. • If a task calls a module and which is not programmed for that task, then that line will be ignored and PAM move on to the next line. • Module-Arguments • Each module accepts different arguments.

8. Control Flags • Depending on if the module passes or fails, the control flag then determines what PAM will tell the application. • Required • Success of the module is required for the module type facility to succeed. Failure of the module will not show to the application until all of the remaining modules have been executed. • Requisite (order sensitive, failure->immediately return) • Like required, however, in the case that such a module returns a failure, control is directly returned to the application. • Gain: It protects against the possibility of a user getting the opportunity to enter a password over an unsafe medium. • Loss: Such behavior might inform an attacker of valid accounts on a system.

9. Control Flags (Cont.) • Sufficient (order sensitive, success->immediately return) • If the module fails, then the module is ignored and the rest of the PAM-Module is executed. • If the module succeeds and no earlier module in the chain has filed, the PAM-Module is immediately terminated and return success. • Optional • This control-flag marks the module as not being critical to the success or failure of the user’s application for service. • In the absence of any definite successes or failures of stacked modules, this module will determine the nature of the response to the application.

10. Example (it also called stack module) Auth required /lib/security/pam_securetty.so #it checks that if the user is trying to login as root, the tty on which they are logging in is listed in the /etc/securetty file. Auth required /lib/security/pam_unix.so shadow nullok #This line causes the user to be asked for a password and then checks the password using the information stored in /etc/passwd and /etc/shadow. Auth required /lib/security/pam_nologin.so #This is the final authentication step. It checks to see if the file /etc/nologin exists. Account required /lib/security/pam_unix.so #It caused any necessary account verification to be done. Password required /lib/security/pam_cracklib.so retry=3 #If password has expired, the password component of the pam_cracklib.so module prompts for a new password. Retry=3 means there have three time for user to create a strong password if he chose a week password. Password required /lib/security/pam_unix.so shadow nullok use_authtok #When change the password, we need pam_unix.so to update shadow password. #shadow: update shadow password file; nullok: password can be empty; use_authtok: Session required /lib/security/pam_unix.so #It logs the username and the service type to /var/log/messages at the beginning and end of each session. Execution order

11. Configuration setup error? • If any of the fields are invalid, or if a module is not found, that line is ignored and the error is logged as a critical error via syslog(3). • All PAM module failure will record in /var/log/message. • Example:

12. PAM Aware Application • Before running the program, we can use PAM APIs to finish authentication of the program. • The application must take responsibility for protecting the environment in which PAM operates.

13. PAM Application Interface • Authentication management API: • pam_authentication(pam_handle_t *pamh, int flags) • It is used to authenticate the user. • pam_setcred(pam_handle_t *pamh, int flags) • It is used to set, refresh or destroy the user credentials. • Account management API: • pam_acct_mgmt(pam_handle_t *pamh, int flags) • It is used to check whether the authenticated user should be given access to his account. In other word, it checks the states of the user account in sure that the account is available. • Session management APIs: • pam_open_session(pam_handle_t *pamh, int flags) • A new session has been initialized. • pam_close_session(pam_handle_t *pamh, int flags) • Upon termination of the session.

14. PAM Application Interface (Cont.) • Password management APIs: • pam_chauthtok() • It is used to change the password. • Administrative Interfaces APIs: • pam_start() • Initializing pam module. • pam_end() • Finishing pam module. • pam_set_item() • pam_get_item() • The above APIs are used to read and write the state information. • pam_strerror() • The error message can be printed with this API.

15. PAM Module API

16. Conversation Function • An application must provides the conversation function used for direct communication between a loaded module and the application. • The structure of pam_conv : struct pam_conv { int (*conv) (int num_msg, const struct pam_message * *msg, struct pam_response * *resp, void *appdata_ptr); void *appdata_ptr; }; • It is initialized by the application before it is passed to the module.

17. Conversation Function (Cont.) Struct pam_message { int msg_style; const char *msg; }; /*The use of pam_message structure is indicating what kind of message style and text should be showed.*/ • msg_style could be the one of followings: • PAM_PROMPT_ECHO_OFF • PAM_PROMPT_ECHO_ON • PAM_ERROR_MSG • PAM_TEXT_INFO Struct pam_response { char *resp; int resp_retcode; }; /*The use of pam_response structure is keeping the result in the resp.*/

18. Transactions in PAM Application • The lifecycle of a typical PAM transaction is described below. If any of these steps fail, the transaction should be aborted. • Calling pam_start(3) to initialize the PAM library and specify its service name and target account, and register a suitable conversation function. • Calling pam_set(3) to set relative information( e.g. username and hostname) • Calling pam_authenticate(3) to authenticate the applicant. • Calling pam_acct_mgmt(3) to verify that the requested account is available and valid. If the password is correct but has expired, app should call pam_chauthtok(3) to force the client to change the authentication token. • Calling pam_setcred(3) to establish the credentials of the requested account. • Once the correct credentials have been established, app calls pam_open_session(3) to set up the session. • Provide the applicant with a shell. • Close the session by using pam_close_session(3). • Finally, app calls pam_end(3) to notify the PAM library that it is done and release whatever resources it has allocated in the course of the transaction.

19. Examples #include <security/pam_appl.h> #include <security/pam_misc.h> #include <pwd.h> #include <sys/types.h> #include <stdio.h> static struct pam_conv pamc = {misc_conv, NULL}; void my_prog() { printf("this is my program!"); } int main() { pam_handle_t *pamh; int result; struct passwd *pw; //save the password printf("start to authenticate\n"); if ((pw=getpwuid(getuid())) == NULL ) perror("getpwuid"); else if (( result = pam_start("su",pw->pw_name, &pamc, &pamh)) != PAM_SUCCESS) fprintf(stderr, " start failed: %d\n", result); else if (( result = pam_authenticate(pamh,0)) != PAM_SUCCESS) fprintf(stderr, " authenticate failed: %d\n", result); else if (( result = pam_acct_mgmt(pamh,0)) != PAM_SUCCESS) fprintf(stderr, " acct_mgmt failed: %d\n",result); else if ((result = pam_end(pamh, result)) !=PAM_SUCCESS) fprintf(stderr, " end failed: %d\n", result); else my_prog(); return 0; }

20. PAM Security Issues • Sharing of passwords with multiple authentication mechanisms. • If user use the same password for all of the authentication mechanisms and any of them is compromised, the user’s password in all systems would be compromised. • Password-mapping. • This technique of encrypting all other passwords with the primary password assumes that it is lot more difficult to crack the primary password. • Security of the configuration file. • The configuration should be protected from unauthorized modifications. • Stacking various PAM modules. • The composition of various authentication modules should be carefully examined. The trusted computing base of the machine now includes the PAM modules.

21. Writing PAM Modules • Authentication Management • pam_sm_authenticate() • pam_sm_setcred() • Account Management • pam_sm_acct_mgmt() • Session Management • pam_sm_open_session() • pam_sm_close_session() • Password Management • pam_sm_chauthtok()