On Tue, Jan 23, 2001 at 01:18:02AM -0500, David MacKenzie wrote:
> Hello! I'm sending this mail to addresses I found in documentation
> for several Linux packages or in changelog entries in their spec files
> for Red Hat or Mandrake Linux. Feel free to forward this message to
> anyone interested that I missed.
Wow. Very cool fixes and summary.
> 2. The utilities call pam_setcred() before, instead of after,
> pam_open_session(). According to the Linux-PAM docs, the RFC
> example code, and the Solaris man page, pam_setcred() should be
> called after pam_open_session().
But pam_setcred() can be called without calling pam_open_session().
Right?
Since su shouldn't call the open/close session calls, should it call
pam_setcred()? In the case of pam_krb5 that would make sense, as long as
pam_setcred() is called again to destroy the ccache when the user exits
the su session. In fact, su might well be useless in a Kerberos
environment unless it does call pam_setcred().
> 7. pam_krb5 makes the pam_sm_{open,close}_session() calls be
> duplicates of the pam_sm_setcred() calls, probably to work around
> bugs 1 and 6. Once they are fixed, pam_krb5 can be corrected, and
> the pam_sm_open_session() and pam_sm_close_session() reduced to
> no-ops that return PAM_SUCCESS, as they should be.
The pam_krb5 pam_sm_close_session() method can do some useful things:
- print the time of last login (i.e., last initial TGT issuance);
granted, MIT doesn't maintain that datum, so it's useless with MIT
krb5
- warn the user about upcoming password expiration (e.g., "Your
password will expire in 3 days")
By the way, there are a number of different pam_krb5 implementations
out there. Few get password aging right (i.e., few give a user with an
expired password the chance to change their password). Kerberos
authentication should be done via the newer
krb5_get_init_creds_with_password() API, not the krb5_get_in_tkt*()
APIs; the former supports password aging, the latter doesn't, and the
former accepts pointers to a krb5_prompter function and related data
which can be used to translate krb5_prompts to PAM prompts. I believe
that Frank Cusak's pam_krb5 calls krb5_get_init_creds_with_password();
Sun's doesn't.
This brings up an issue with PAM and the Kerberos password aging model,
namely that with Kerberos an expired password must be changed BEFORE
proceeding with authentication, but in the PAM model authentication is
done first, then authorization and only then can password expiration be
discovered and corrected (i.e., it's pam_acct_mgmt()'s job to indicate
the password expired case to the application so it cam call
pam_chauthtok()).
I think the solution is for pam_krb5:pam_sm_authenticate() to work
through changing a user's old password when it's expired, without
setting the PAM_*AUTHTOK items, leaving that to
pam_krb5:pam_sm_chauthtok() and using pam_set_data() to keep state.
Alternatively, pam_krb5:pam_sm_authenticate() could provisionally return
PAM_SUCCESS in password expired cases, then pam_krb5:pam_sm_acct_mgmt()
can return PAM_NEW_AUTHTOK_REQD, and then pam_krb5:pam_sm_chauthtok()
return PAM_SUCCESS/PAM_PERM_DENIED/PAM_AUTH_ERR and so on. Applications
MUST treat pam_chauthtok() as if it were pam_authenticate() in such
cases and deny access unless pam_chauthtok() returns PAM_SUCCESS.
The latter solution is harder to implement in pam_krb5 than the former,
needing several calls to krb5_get_init_creds_with_password() instead of
just one call.
Clarification in this area would be appreciated. I would prefer the
simpler approach.
> 8. pam_krb5 lacks an account management function to check .k5login for
> authorization.
> 9. pam_krb5 doesn't check some malloc calls for failure.
...
This depends on which implementation of pam_krb5 you're referring to...
:)
Nico
--
