[gentoo-user] Pam configuration for winbind

[gentoo-user] Pam configuration for winbind

[Michael Jones]

[-- Attachment #1: Type: text/plain, Size: 3837 bytes --]

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




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

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.

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.

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?

5. Why use [default=die] instead of requisite for pam_faillock.so in the
auth section?

[-- Attachment #2: Type: text/html, Size: 4813 bytes --]

Re: [gentoo-user] Pam configuration for winbind

[Michael]

[-- Attachment #1: Type: text/plain, Size: 6133 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]