Mailing List Archive

Pam configuration for winbind
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?
Re: Pam configuration for winbind [ In reply to ]
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.