Bug#1001644: libpam-sss: OTP-enabled users do not recieve OTP prompts from pam_sss.so

[Sam Morris]

Package: libpam-sss
Version: 2.6.1-1
Severity: normal

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

In the default configuration, /etc/pam.d/common-auth contains:

auth [success=2 default=ignore] pam_unix.so nullok
auth [success=1 default=ignore] pam_sss.so use_first_pass
auth requisite pam_deny.so

This means that pam_unix has the first & only change to prompt the user
for authentication, and the user gets a single 'Password:' prompt.

In the Red Hat world, /etc/pam.d/password-auth contains:

auth required pam_env.so
auth required pam_faildelay.so delay=2000000
auth [default=1 ignore=ignore success=ok] pam_usertype.so isregular
auth [default=1 ignore=ignore success=ok] pam_localuser.so
auth sufficient pam_unix.so nullok
auth [default=1 ignore=ignore success=ok] pam_usertype.so isregular
auth sufficient pam_sss.so forward_pass
auth required pam_deny.so

A local user will hit pam_unix. A non-local user will skip over it and
be prompted by pam_sss.so.

An easy fix is to increase the Priority in /usr/share/pam-configs/sss to
some value > 256. That way, pam-auth-update puts pam_sss before
pam_unix.

I tested this, and 'su - localuser' still works.

Unfortunately I don't know of a way for a user to override this value
other than by editing that file, which is owned by libpam-sss.

Is there a good reason that pam_unix has to be first in the module
stack? If not, could we make this change?

- -- System Information:
Debian Release: 11.1
APT prefers stable-updates
APT policy: (550, 'stable-updates'), (550, 'stable'), (530, 'testing'), (520, 'unstable'), (500, 'stable-security'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libpam-sss depends on:
ii libc6 2.32-5
ii libgssapi-krb5-2 1.18.3-7
ii libpam-pwquality 1.4.4-1
ii libpam-runtime 1.4.0-9+deb11u1
ii libpam0g 1.4.0-11

Versions of packages libpam-sss recommends:
ii sssd 2.6.1-1

libpam-sss suggests no packages.

- -- no debconf information

-----BEGIN PGP SIGNATURE-----

iIgEARYIADAWIQTWOGqGn6HETecdzqZOEaKLhlAYigUCYbeFXRIcc2FtQHJvYm90
cy5vcmcudWsACgkQThGii4ZQGIpR9gEAldojCYmY4mvOcns5k9wcfXpTN324+MUx
wiiKCeGy5PgBAKsWW6nGrvuFyQggaQADHH5O1p+bdr5q35Bp4suL0w0A
=ldXe
-----END PGP SIGNATURE-----

[Timo Aaltonen]

On 13.12.2021 19.39, Sam Morris wrote:
> Package: libpam-sss
> Version: 2.6.1-1
> Severity: normal
>

You're asking in the wrong place.. Anyway, pam_sss is not above pam_unix
in Fedora either, so why should it have a higher priority here?



--
t

[Sam Morris]

My goal is to get 2-factor authentication working on Debian systems as
easily as it does on Fedora/RHEL systems. This requires pam_sss to
prompt the user for their password, not pam_unix.

Here's a solution that uses pam_localuser to prevent pam_unix from being
invoked for pam_sss's users:

# here are the per-package modules (the "Primary" block)

auth [default=1 ignore=ignore success=ok] pam_localuser.so

auth [success=2 default=ignore] pam_unix.so nullok
auth [success=1 default=ignore] pam_sss.so

# here's the fallback if no module succeeds
auth requisite pam_deny.so

But, this another package to change for us (libpam-modules which ships
/usr/share/pam-configs/unix). We can ask, of course....

For this to work, I had to remove the 'use_first_pass' option from
pam_sss. Otherwise FreeIPA users can't log in any more:

(2022-02-01 10:22:06): [be[ipa.example.com]] [krb5_auth_send] (0x0020): Illegal empty authtok for user [us...@ipa.example.com]

Unfortunately pam_sss doesn't have a 'try_first_pass' option. As a
result, if there is _another_ module that runs before pam_sss, AND
prompts the user for a password, storing itin the PAM environment,
pam_sss will not use it, and the user will be prompted for their
'password' or 'first factor' (depending on whether the user requires
MFA) a second time.

Even if 'try_first_pass' did exist in pam_sss, the user would still get
a 'password' prompt instead of a 'first factor' prompt, which is an
annoying behaviour difference between how things work in the Debian
universe rather than the Red Hat universe. The only fix for that is for
every other PAM module to avoid prompting for a password if the user is
'not for them', so that pam_sss still gets to be the first/only module
that prompts for a password, even though it is later on in the stack.

Because of requiring extra work in the libpam-modules package, and the
edge case above, it seems simpler to re-arrange the stack so that
pam_sss goes first.

So, we can either bump the priority of pam_sss, or remove the
use_first_pass option iff the PAM maintainers agree to add pam_localuser
to their pam-auth-update config file. What do you think?

--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9