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
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Dave Reisner (falconindy)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

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
Comment by Ingo Albrecht (indigo) - Monday, 21 March 2016, 10:08 GMT
I garbled two sentences in the bug report which I want to clarify:
- 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.
Comment by Dave Reisner (falconindy) - Saturday, 05 January 2019, 14:50 GMT
This seems fine, but the fallout could be substantial. There's already at least one program (runuser) which does not yet have PAM definitions. I don't know of a good way to determine when "other" is used on my system, or in aggregate across a larger number of users to avoid problems.
Comment by Dave Reisner (falconindy) - Saturday, 05 January 2019, 15:31 GMT
pambase-20190105.1-1 now uses the upstream "other" template.

Loading...