FS#48650 - [pambase] "other" template is non-upstream
Attached to Project:
Arch Linux
Opened by Ingo Albrecht (indigo) - Sunday, 20 March 2016, 23:16 GMT
Last edited by Dave Reisner (falconindy) - Saturday, 05 January 2019, 15:31 GMT
Opened by Ingo Albrecht (indigo) - Sunday, 20 March 2016, 23:16 GMT
Last edited by Dave Reisner (falconindy) - Saturday, 05 January 2019, 15:31 GMT
|
Details
Description:
The pambase package ships default pam templates for Arch Linux. It includes the default configuration file "other", which applies anytime a pam-aware application has no configuration in /etc/pam.d/ Since PAM release 1 the default policy for "other" has been to warn and deny.[1] Arch however, ships a permissive policy, which the PAM project explicitly warns about [2]. --> The default "other" policy should be changed to upstream.[2] To safeguard against breakage (bug reports from users whose existing systems where the upstream is currently applied by applications), it may be useful to comment out the permissive current policy and add a sentence about reverting to upstream. Additional info: The current default Arch configuration shipped is ## #%PAM-1.0 auth required pam_unix.so account required pam_unix.so password required pam_unix.so session required pam_unix.so which dates back to [3], [4] The risk of this default is twofold: 1. a shipped pam-aware application misses its necessary configuration file for /etc/pam.d. This will go unnoticed and escape the desired runtime application of the "system-*" pambase policies. I do understand a permissive "other" may be of some use, assuming users install a foreign package and are unaware of the pam-stack. - it will fail to work, but that is exactly the reason the "other" template should be warning. It is a packaging error like any other. 2. Configuration errors are easier. For example, a user may mod /etc/pam.d/system-auth to include another authentication method. Any application handled by "other" will escape such. Do I fail to see an other reason to use "permissive mode" other than convenience? Steps to reproduce: Simply point a service of your choice, e.g. /etc/pam.d/sshd explicitly to "other" for the control objects. Try the upstream "other" template and check the journal to see the warning. [1] https://git.fedorahosted.org/cgit/linux-pam.git/commit/conf/pam.conf?h=Linux-PAM-1_1_3&id=ea488580c42e8918445a945484de3c8a5addc761 [1] Line fixed "other" for latest release: https://git.fedorahosted.org/cgit/linux-pam.git/tree/conf/pam.conf?h=Linux-PAM-1_2_1#n55 [2] http://www.linux-pam.org/Linux-PAM-html/sag-security-issues-other.html [3] https://projects.archlinux.org/svntogit/packages.git/commit/trunk/other?h=packages/pam&id=4deb4d722c01323596e169e1d9b9e86f371d5d8c [4] https://projects.archlinux.org/svntogit/packages.git/commit/trunk/other?h=packages/pambase&id=b27b10005bf36cf3e91de958736e20fb27189b86 |
This task depends upon
Closed by Dave Reisner (falconindy)
Saturday, 05 January 2019, 15:31 GMT
Reason for closing: Fixed
Additional comments about closing: testing/pambase-20190105.1-1
Saturday, 05 January 2019, 15:31 GMT
Reason for closing: Fixed
Additional comments about closing: testing/pambase-20190105.1-1
- The safeguard against breakage I mention: I simply want to suggest that when "other" is changed to upstream, a comment about the change is left in the "other" template so that users who have erroneous pam.d config for a service at the moment get a quick hint.
- related to above I garbled "I do understand a permissive "other" may be of some use, assuming users install a foreign package and are unaware of the pam-stack. - it will fail to work, but that is exactly the reason the "other" template should be warning. It is a packaging error like any other."
It will fail to work, _if_ the current default is changed to upstream. The fail with warn/deny is the intended behaviour of the non-permissive upstream default.
Other than that, this report is (obviously) security-related. When evaluating whether upstream is implemented, consider that there may have been more problems with services at the time when the Arch default was first shipped.[3] I would imagine the permissive default may have been used first in order not to break services which are not ready for pambase rollout yet. But by now all should have adjusted config.