Feature request: default PAM / authselect profiles

[breakwaterlabs]

Out of the box, the CentOS / RedHat (and I assume Debian, etc) packages do not configure PAM for 2fa. Instead, the documentation instructs the user to,

modify your system's PAM configuration to include a line like the following...

auth required pam_duo.so

This is not only vague and unhelpful for many administrators (who may not frequently visit PAM and its eccentricities), it is incorrect on systems like RHEL / CentOS / Rocky 8 where authselect controls the /etc/pam.d directory and all of its files. In particular, someone modifying e.g. /etc/pam.d/system-auth to require 2fa may find that their change gets overwritten on a system update or on enabling smartcard login when authselect helpfully reapplies the current profile.

A better option-- at least on RPM systems-- would be to ship an authselect profile at /usr/share/authselect/duo or /etc/authselect/custom/duo-local. Authselect allows creating option-driven PAM templates; as an example, take the following snippet from a modified, duo-compatible sssd authselect profile:

auth  required     pam_env.so
auth  required     pam_faildelay.so delay=2000000
auth  required     pam_deny.so # Smartcard authentication is required     {include if "with-smartcard-required"}
auth  required     pam_faillock.so preauth silent deny=4 unlock_time=120  {include if "with-faillock"}
auth  sufficient   pam_u2f.so cue                                         {include if "with-pam-u2f"}
auth  required     pam_u2f.so cue nouserok                                {include if "with-pam-u2f-2fa"}
....
....
auth  requisite    pam_succeed_if.so uid >= 1000 quiet_success
auth  sufficient   pam_sss.so forward_pass                                {exclude if "with-duo"}
auth  requisite    pam_sss.so forward_pass                                {include if "with-duo"}
auth  sufficient   pam_duo.so                                             {include if "with-duo"}
auth  required     pam_faillock.so authfail deny=4 unlock_time=120        {include if "with-faillock"}
auth  required     pam_deny.so

One can enable this profile with several options, which control the inclusion or exclusion of the corresponding lines. For instance if one were to enable the profile with, authselect select sssd, you would get the basic SSSD PAM profile without any of the 'include-if' lines:

auth  required     pam_env.so
auth  required     pam_faildelay.so delay=2000000
auth  requisite    pam_succeed_if.so uid >= 1000 quiet_success
auth  sufficient   pam_sss.so forward_pass
auth  required     pam_deny.so

If you were to enable the profile with authselect select sssd with-duo, the resultant PAM file would look something like this:

auth  required     pam_env.so
auth  required     pam_faildelay.so delay=2000000
auth  requisite    pam_succeed_if.so uid >= 1000 quiet_success
auth  requisite    pam_sss.so forward_pass 
auth  sufficient   pam_duo.so  
auth  required     pam_deny.so

Red Hat has committed to using authselect at least with 8 and on, and creating a custom authselect profile to cover the basic use cases (SSSD, winbind, local) is a minor task that would drastically simplify the process of enabling duo while avoiding pitfalls of conflicting PAM file modification.

[breakwaterlabs]

If there is interest in this feature I would be happy to write the code and issue a pull request.

[Sepiidae]

This is an older feature request, but I agree this is needed. We deploy IPA on an HPC cluster and activating ipa disables Duo upon enrollment.

AUTH profiles do a great job of decreasing the risk of really messing up your PAM configuration. I know certain admin (me) who's initial setup disabled password authentication in favor of just using duo. Oppps...

[AaronAtDuo]

Thanks for the offers and interest, but we are unlikely to proceed with this feature request.

On paper this seems like a great idea. However, multiple years of handling questions from customers about their PAM stacks has taught us that Duo trying to be helpful with PAM configuration actually just makes things worse. It seems like every customer wants something different from their PAM stack; while the authselect templates address that, it requires those admins to have to understand both the authselect mechanisms and the resultant PAM stack in order to configure their system appropriately. So instead, many admins, in a rush, just copy anything Duo provides and this leads to a worse outcome for both them and us.

That being said, if there's a way to introduce authselect profiles in a way that makes it easier for admins to get the correct PAM configuration, while having to understand PAM and authselect less, that would be ideal!

[breakwaterlabs]

Aaron, There are two issues here. The first is that duo's documentation is flat out incorrect here as authselect is a default part of the RHEL 8 stack, and thus modifying pam files directly *will* result in breakage at some future point. The manner and timing of that breakage are both hard to predict, making this pretty much the most obnoxious sort of stealth misconfiguration. The second issue is precisely that everyone's stack is different, and a blanket suggestion "insert this line into your pam" is not going to generally work. However, authselect ships 3 standard profiles and those are good starting points for one or two custom profiles. If Duo were to suggest and maintain two basic profiles-- local auth, and SSSD-- and were to clearly explain what they do and that they don't cover every use case (e.g. smartcards), you would cover 95% of use cases while also enabling people to try the profile out without potentially breaking their auth stack and locking themselves out. Given Red Hat's strong commitment to auth select, this seems somewhat mandated by the choice of supported platform anyways.

…

On Fri, Jan 20, 2023 at 2:31 PM Aaron ***@***.***> wrote: Thanks for the offers and interest, but we are unlikely to proceed with this feature request. On paper this seems like a great idea. However, multiple years of handling questions from customers about their PAM stacks has taught us that Duo trying to be helpful with PAM configuration actually just makes things worse. It seems like every customer wants something different from their PAM stack; while the authselect templates address that, it requires those admins to have to understand *both* the authselect mechanisms and the resultant PAM stack in order to configure their system appropriately. So instead, many admins, in a rush, just copy anything Duo provides and this leads to a worse outcome for both them and us. That being said, if there's a way to introduce authselect profiles in a way that makes it *easier* for admins to get the correct PAM configuration, while having to understand PAM and authselect *less*, that would be ideal! — Reply to this email directly, view it on GitHub <#218 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACGLX3NVR6H2BBZHIFIMAJLWTLRXNANCNFSM5PERWGSQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[kfiresmith]

Basically what @breakwaterlabs said in their prior comment, but from the Ubuntu perspective.

Ubuntu uses pam-auth-update via profiles that are created specifically to prevent future landmines when something else changes the stack the right way - via package provided profiles.

You can read more about this at https://wiki.ubuntu.com/PAMConfigFrameworkSpec

Authselect and pam-auth-update were created specifically to do what @AaronAtDuo mentioned in his last comment:

if there's a way to introduce authselect profiles in a way that makes it easier for admins to get the correct PAM configuration, while having to understand PAM and authselect less, that would be ideal!