On Wednesday, 14 October 2020 21:18:38 GMT Michael Jones wrote: > With the recent update to sys-auth/pambase-20201013, i find myself > struggling to understand how to adapt the new default configuration to work > with winbind. > > I'm writing to the list for help with this. > > First, I'll provide my current system-auth, the new system-auth that comes > from sys-auth/pambase-20201013, and my attempt at merging the two versions. > After those items, I have several questions which I'll ask at the end of my > email. > > > > First, here's my current /etc/pam.d/system-auth file: > > auth required pam_env.so > auth sufficient pam_unix.so try_first_pass likeauth nullok > auth sufficient pam_winbind.so use_first_pass > auth required pam_deny.so > > account sufficient pam_unix.so > account required pam_winbind.so > > password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 > retry=3 > password sufficient pam_unix.so try_first_pass use_authtok nullok sha512 > shadow > password sufficient pam_winbind.so use_authtok > password optional pam_permit.so > > session required pam_limits.so > session required pam_env.so > session required pam_unix.so > session required pam_winbind.so > session optional pam_permit.so > > > Here's the new version that comes from sys-auth/pambase-20201013 with the > useflags: gnome-keyring nullok passwdqc sha512 systemd > > auth required pam_env.so > auth required pam_unix.so try_first_pass likeauth nullok > auth optional pam_permit.so > auth required pam_faillock.so preauth > auth sufficient pam_unix.so nullok try_first_pass > auth [default=die] pam_faillock.so authfail > account required pam_unix.so > account optional pam_permit.so > account required pam_faillock.so > password required pam_passwdqc.so config=/etc/security/passwdqc.conf > password required pam_unix.so try_first_pass use_authtok nullok sha512 > shadow > password optional pam_permit.so > session required pam_limits.so > session required pam_env.so > session required pam_unix.so > session optional pam_permit.so > > > Here's my attempt at merging these two together. > > auth required pam_env.so > auth required pam_faillock.so preauth > auth sufficient pam_unix.so nullok try_first_pass > auth sufficient pam_winbind.so use_first_pass > auth requisite pam_faillock.so authfail > > account required pam_faillock.so > account sufficient pam_unix.so > account sufficient pam_winbind.so > account optional pam_permit.so > > password required pam_passwdqc.so > config=/etc/security/passwdqc.conf > password sufficient pam_unix.so try_first_pass use_authtok nullok > sha512 shadow > password sufficient pam_winbind.so use_authtok > password optional pam_permit.so > > session required pam_limits.so > session required pam_env.so > session required pam_unix.so > session required pam_winbind.so > session optional pam_permit.so
I'd rather not comment on the above in case my understanding is incorrect and you end up breaking access to your system. ;-) Some answers/thoughts below. > Questions: > > 1. Why does sys-auth/pambase use the "likeauth" flag? I cannot find any > real information about this except for a redhat bugzilla ticket that says > it's for legacy usage from 2004. > https://bugzilla.redhat.com/show_bug.cgi?id=120418 I don't know if this is still required, or is now deprecated. This thread referenced in the bug you mention provides some explanation: https://www.spinics.net/lists/pam/msg03533.html I understand it to mean when an application asks pam_unix.so to set a new passwd this will use the same authentication criteria/limits checks, as an existing authentication credentials would be normally checked against. > 2. Why is pam_faillock.so used with "preauth" after the first use of > pam_unix.so ? The manpage for pam_faillock.so says that faillock should be > called with the "preauth" command prior to asking for the user's password. I think if the pam_unix.so in the preceding line has been used by an application to set a new passwd, the passwd will be asked/checked at the subsequent pam_unix.so line, which is below the pam_faillock.so. I admit this logic is not particularly sound, if the preceding pam_unix.so line is not setting a new passwd, just asking/checking what is submitted. :-/ > 3. Why is pam_permit.so used as the last item in each section other than > auth? The manpage for pam_permit indicates that this module always returns > success. Using it as an optional module is a no-op. The pam_permit module is meant to set an application user as 'nobody', some applications run with this user name and no passwd. The optional control flag means it will continue checking the rest of the stack. > 4. Why is pam_faillock.so the last module for the "account" type, instead > of the first module, as from the example in the manpage? The preceding control flag is set to be 'sufficient' for pam_unix.so. If the pam_unix.so succeeds and no previous 'required' modules have failed, any modules following it will not be checked. Authentication would have been successful. If however, failures have already taken place in previous checks in the stack or in the current pam_unix.so check, subsequently the pam_faillock.so will be checked against. > 5. Why use [default=die] instead of requisite for pam_faillock.so in the > auth section? I think 'requisite' will inform the application of repeated failed authentications and consequently inform an attacker of potentially valid user accounts. The [default=die] will cause pam_faillock.so to register an authentication failure and in addition terminate pam and cancel any futher checks down the module stack. My understanding of PAM is ropey to put it mildly, so someone more versed in its logic should hopefully chime in to correct any mistakes.
signature.asc
Description: This is a digitally signed message part.
