Bug in handling of AUTHTOK item

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



libpam/pam_item.c contains the following comment:

    case PAM_AUTHTOK:
         /*
          * The man page says this is only supposed to be available to
          * the module providers.  In order to use this item the app
          * has to #include <security/pam_modules.h>. This is something
          * it is *not* supposed to do with "Linux-"PAM!  - AGM.
          */

I think, however, that to better accommodate applications that prompt for
a username AND password before calling PAM, PAM SHOULD allow
applications to _set_ the PAM_AUTHTOK item.

An example of such an application would be XDM. There are others.

Also, I would argue that the *TOK item access control mechanism
implemented by LinuxPAM is horrid. Moreover, the comment does not
document what else is done, namely that pam_authenticate() (et. al.)
call _pam_sanitize() before and after calling all the modules, and that
_pam_sanitize() overwrites and removes the PAM_AUTHTOK and PAM_OLDAUTHTOK
items.

Better to have a flag in the PAM handle structure that indicates whether
or not the process is currently in pam_authenticate() or pam_acct_mgmt()
or pam_chauthtok() and so on. This flag should be checked by
pam_get_item() to disallow access to PAM_AUTHTOK and PAM_OLDAUTHTOK to
applications; pam_set_item() should allow applications to set
PAM_AUTHTOK, but not PAM_OLDAUTHTOK and then only before the application
calls pam_authenticate().

Besides XDM, consider a module which performs password ageing in its
pam_sm_authenticate() method, rather than in combination with its
acct_mgmt() and chauthtok() methods.

This may well be the case with implementations of PAM_KRB5 because the
way Kerberos password aging works makes it impossible to validate an
expired password before changing it (and afterwards only the new
password can be validated).

Such modules will have to perform the password change in
pam_sm_authenticate() and then the PAM_OLDAUTHTOK should survive
pam_authenticate() such that other modules' pam_sm_chauthtok() methods
could reference it and PAM_AUTHTOK as set/modified in
pam_authenticate().

Alternatively such modules (e.g., PAM_KRB5) could provisionally return
PAM_SUCCESS from their pam_sm_authenticate(), PAM_NEW_AUTHTOK_REQD from
their pam_sm_acct_mgmt() and perform authentication in their
pam_sm_chauthtok().

Nico
--





[Index of Archives]     [Fedora Users]     [Kernel]     [Red Hat Install]     [Linux for the blind]     [Gimp]

  Powered by Linux