Gebruikershulpmiddelen

Site-hulpmiddelen


linux:pam:pam_mini-howto

Verschillen

Dit geeft de verschillen weer tussen de geselecteerde revisie en de huidige revisie van de pagina.

Link naar deze vergelijking

linux:pam:pam_mini-howto [2018/12/30 17:17]
linux:pam:pam_mini-howto [2018/12/30 17:17] (huidige)
Regel 1: Regel 1:
 +====== PAM MINI-HOWTO ======
 +
 +===== 0. PREREQUISITES =====
 +
 +OS: Debian "​Woody"​ with 2.4 kernel (Linux-PAM will be installed by default)\\ ​ Docs: install "​**libpam-doc 0.72-35**"​ from CD-4 "​unofficial extras"​\\
 +
 +===== 1. PAM SUMMARY =====
 +
 +PAM ("​Pluggable Authentication Modules"​) is a set of library modules that an application may\\ use for user authentication.\\ ​ If it does, such an application is said to be "​PAM-aware"​ and to offer "a restrictive service"​.\\ ​ (Use the "​**ldd**"​ command to check if an application is "​PAM-aware"​.)\\ ​ PAM was originally developed by SUN Microsystems.\\ ​ It offers the big advantage of being able to dynamically switch between authentication methods\\ without having to rewrite the PAM-aware application.
 +
 +The library modules (dynamically loadable object files) reside in **/​lib/​security**.\\ ​ (On some Linux platforms: /​usr/​lib/​security)\\ ​ Some of these modules need special files which usually reside in **/​etc/​security**.\\ ​ These files should be provided by default, but may contain commentary lines only.\\ ​ They all have a specific format and may be modified by the superuser.\\ ​ Modules may be able to log information via **syslogd**,​ so you may wish to edit **/​etc/​syslog.conf**\\ ​ (Hint: check if basic logging of authentication has already been set to: **/​var/​log/​auth.log**)
 +
 +The behavior of "​restrictive/​PAM-aware"​ services is managed via the **PAM configuration file(s)**.\\ ​ Originally PAM used one configuration file (/​etc/​pam.conf) that contained lines (so-called "​rules"​)\\ ​ of a specific 5-fields-format:​ service module-type control-flag module-path argument(s).\\ ​ Nowadays PAM uses a special directory (**/​etc/​pam.d**) which contains one configuration file\\ per "​restrictive service"​.\\ ​ As **file name=service name**, the lines in these files are of the following 4-fields-format:​\\ **module-type control-flag module-path argument(s)**
 +
 +The directory also contains a special file (**/​etc/​pam.d/​other**).\\ ​ This file is used by all restrictive services that haven'​t got a proper config file of their own.\\ ​ It usually specifies a default authentication method (like basic Unix-authentication),​\\ but could/​should be made more restrictive if necessary.
 +
 +Directory-based PAM configuration offers many advantages:​\\ ​ - quicker to parse \\  - easier to maintain (no risk to affect behavior of another "​service"​)\\ ​ - access permissions per file allow f.i. limitation of "​read"​ access per file\\ ​ - possibility to link config files to a single file\\
 +
 +Note:​\\ ​ On most Linux platforms, PAM will be compiled to support just **one** config file method.\\ ​ This means that if both /​etc/​pam.conf and /​etc/​pam.d/​* exist,​\\ ​ /​etc/​pam.conf will be ignored and the config files in /etc/pam.d will be used.\\ ​ In the absence of /etc/pam.d, /​etc/​pam.conf will be used.\\ ​ However, on some Linux platforms, PAM will be compliled to support **both** config file methods.\\ ​ In that case, "​rules"​ in /etc/pam.d override those in /​etc/​pam.conf\\
 +
 +===== 2. PAM CONFIG FILE LAYOUT (/​etc/​pam.d) =====
 +
 +First of all: file name=service name; must be in **lower case**.\\ ​ The use of "#"​ (for commentary) and of "\ <​return>"​ is allowed.\\ ​ Each line ("​rule"​) consists of **4 fields** separated by white space:\\
 +
 +| **module-type** | **control-flag** | **module-path** | **argument(s)** |
 +
 +Example: **auth required pam_rootok.so debug**\\ ​ User must be superuser ('​required'​),​ if not: authentication fails; '​debug'​ will log via syslogd
 +
 +==== 4 module-types (all in lower case) are allowed: ====
 +
 +- **auth:** handles the authentication process (asks for and checks password)\\ ​ - **account:​** checks if authentication is allowed at all (checks if account hasn't expired)\\ ​ - **password:​** handles setting/​changing of passwords (checks if requirements have been met)\\ ​ - **session:​** handles use of account after successful authentication (uses /​etc/​passwd)\\
 +
 +==== 4 control flags (all in lower case) are allowed: ====
 +
 +| - **requisite:​** | success is required; if module fails, the authentication\\ ​ process is terminated immediately and control is returned\\ ​ to the application |
 +| - **required:​** | success is required; if module fails, other modules of the\\  same type will still execute, but thereafter, the user will\\ ​ be informed of the fact that authentication failed |
 +| - **sufficient:​ ** | if no previous '​required'​ module of the same type has failed,​\\ ​ success of this module is sufficient and subsequent modules\\ ​ of this type won't be invoked; should this module fail, the\\  next module of the same type will be invoked |
 +| - **optional: ** | success/​failure will be ignored by PAM, unless this is the\\  only module of this type to be invoked |
 +
 +==== module-path:​ ====
 +
 +Correct path name to the compiled library module'​s file.\\ ​ The compiled library modules are located in /​lib/​security (or /​usr/​lib/​security).\\ ​ Relative path names may be supported.
 +
 +==== argument(s):​ ====
 +
 +A **space separated** list of **module-specific** arguments, usually in lower case.\\ ​ May include '​debug'​ or '​audit'​ to indicate logging level.
 +
 +Note:​\\ ​ Modules may be "​**stacked**",​ i.e. a config file may start by 3 or 4 "​auth"​-module lines.\\ ​ In that case the correct order of lines and the correct use of control flags are very important!\\ ​ (see: '​su'​ examples in part 3 of this document)\\
 +
 +===== 3. SOME EXAMPLES FOR "​auth"​ in /​etc/​pam.d/​su =====
 +
 +If you want to experiment with these examples: first of all, move '​su'​ to '​su.org'​\\ ​ and create your own '​su'​-file!\\ ​ Next, check '​su'​ behavior for 3 types of user:​\\ ​ the root-user, a user who is a "​wheel/​root-group"​ member and a normal user.\\ ​ Hint: take a good look at the logfile(s)!
 +
 +**Ex.1:** Enable normal '​su'​ for root; block '​su'​ for all other users\\
 +
 +|  ||||| **auth** | **sufficient** | **pam_rootok.so** | **debug** |
 +
 +If you are the root-user, this will succeed: you may still '​su'​ without providing a password.\\ ​ If you are NOT the root-user, this will fail and you'll get "su: Permission denied"​.\\ ​ Note: if this is the only line in the file, there'​s no difference in '​su'​ behavior if the control\\ ​ flag is set to '​required'​!
 +
 +**Ex.2:** Enable normal '​su'​ for root and for all other users\\
 +
 +|  ||||| **auth** | **sufficient** | **pam_rootok.so** | **debug** |
 +|  ||||| **auth** | **required** | **pam_unix.so** | **debug** |
 +
 +If you are the root-user, line 1 will succeed and because of the '​sufficient'​ flag, line 2\\  won't be invoked at all. The root-user will be able to '​su'​ without providing a password.\\ ​ If you are NOT the root-user, line 1 will fail, but because of the '​sufficient'​ flag, line 2\\  will be invoked.\\ ​ Line 2 will allow all non-root users to '​su',​ but they MUST provide a correct PASSWORD.\\ ​ Note:​\\ ​ If the control flag in the first line is set to '​required',​ this will make a lot of difference!\\ ​ For the root-user this means that he will need to provide a PASSWORD any time he uses '​su'​!\\ ​ This bit of authentication is handled by line 2. Then, both requirements will have been met.\\ ​ For non-root-users,​ line 1 will still fail, but line 2 will be executed nevertheless\\ ​ (user will get "​Password:"​ prompt).\\ ​ Even so, if one of the '​required'​ steps for a certain type of authentication fails, the summarized\\ ​ PAM report on that type of authentication will still be "​FAIL"​!\\ ​ So access to '​su'​ will be blocked to any non-root-user!!
 +
 +**Ex.3:** Enable normal '​su'​ for root PLUS '​su'​ to root-account for all "​wheel-group"​ members\\
 +
 +|  ||||| **auth** | **sufficient** | **pam_rootok.so** | **debug** |
 +|  ||||| **auth** | **required** | **pam_wheel.so** | **trust debug** |
 +
 +The pam_wheel.so module handles access to the root-account.\\ ​ (It is NOT APPLICABLE if access to non-root accounts must be handled!)\\ ​ Access is based on membership of the "​**wheel-group**"​ in **/​etc/​group**.\\ ​ (It is NOT based on the login-group in /​etc/​passwd!)\\ ​ If there'​s no "​wheel-group",​ the "​root-group"​ (**GID=0**) is the **default**.\\ ​ Note: add "​**group=//​groupname//​**"​ to restrict access to another group than the "​wheel-group"​.\\
 +
 +For "​wheel-group"​ members, line 1 will fail, but line 2 will succeed.\\ ​ The '​trust'​ argument will allow them to '​su'​ to the root-account without providing a password.\\ ​ They won't be allowed to '​su'​ to any other account though (no authentication provided for that!).\\ ​ Due to this configuration,​ other users can't use '​su'​ at all (no authentication provided for them!).\\ ​ Note: don't leave out '​trust',​ for non-trusted access requires a password and that can'​t\\ ​ be handled by pam_wheel.so! Solution: compare Ex.4 to ex.5!!
 +
 +**Ex.4: **Is this a safe one?? \\
 +
 +|  ||||| **auth** | **sufficient** | **pam_rootok.so** | **debug** |
 +|  ||||| **auth** | **sufficient** | **pam_wheel.so** | **debug** |
 +|  ||||| **auth** | **required** | **pam_unix.so** | **debug** |
 +
 +Line 1 will offer normal '​su'​ behavior to the root-user.\\ ​ If a "​wheel-group"​ member wants to '​su'​ to the root-account,​ line 1 will fail,​\\ ​ but line 2 will succeed. Because there is no '​trust'​ argument, he will have to provide\\ ​ a correct root-PASSWORD! This can only be handled if line 3 is present!\\ ​ If a "​wheel-group"​ member wants to '​su'​ to a non-root-user account, line 1 will fail\\ ​ and line 2 won't be applicable. Access will then be handled by line 3, which means he\\  will have to provide a PASSWORD!\\ ​ In short, this will allow "​wheel-group"​ members access to ALL accounts if they\\ ​ know the password!\\ ​ For all other users: if they want to '​su'​ to the root-account,​ both lines 1 and 2 will fail,​\\ ​ but because of the '​sufficient'​ flags, line 3 will still be invoked and allow them access\\ ​ if they know the root-PASSWORD.\\ ​ Equally they will gain access to all other accounts via line 3 (line 1 will fail, line 2 won'​t\\ ​ be applicable).
 +
 +**Ex.5: **This might be better!\\
 +
 +|  ||||| **auth** | **sufficient** | **pam_rootok.so** | **debug** |
 +|  ||||| **auth** | **required** | **pam_wheel.so** | **debug** |
 +|  ||||| **auth** | **required** | **pam_unix.so** | **debug** |
 +
 +The '​required'​ flag in line 2 blocks access to the root-account to non-wheel-members.\\ ​ This '​su'​ configuration offers normal '​su'​ behavior to the root user.\\ ​ "​wheel-group"​ members will be allowed to '​su'​ to ALL accounts including the\\  root-account,​ if they know the PASSWORD.\\ ​ Other users will be allowed to '​su'​ to accounts of other users if they know the PASSWORD\\ ​ (line 1 will fail, line 2 won't be applicable, line 3 will handle access).\\ ​ Access to the root-account is blocked to them as they can't meet the requirement in line 2\\  (they will get a "​Password:"​ prompt, but the summarized authentication report will be: FAIL).
 +
 +Copyright (C) 2002 Integrated Services; tux4u.nl\\ ​ Author: Drs.M.Waldorp-Bonk\\ ​ pam_mini-howto.html 20021113
  
linux/pam/pam_mini-howto.txt ยท Laatst gewijzigd: 2018/12/30 17:17 (Externe bewerking)