On Fri, Oct 23, 2009 at 10:22:02AM -0500, Douglas E. Engert wrote:
> Will Fiveash wrote:
> >That is the plan. This is also why pam_krb5 when doing PKINIT should be
> >stacked above pam_authtok_get to avoid pam_authtok_get's prompting for a
> >password inappropriately.
>
> Login is easy. Screen unlock is much harder. Make sure you plan will
> work with the actions the user must preform and in what order they are
> preformed and what is happening internally.
>
> User walks up to a screen saver on screen and moves the mouse or hit a key
> to see if its locked or not.
>
> screen saver calls PAM with logined in username. In current
> configurations, the first thing the user see is enter password.
>
> The user may or may have not inserted a smartcard yet. If you skip
> pam_authtok_get and use pam_krb5 first you may have started the process to
> see if a card is present.
If you wanted the PAM_USER to be derived from the smartcard, then the
smae sort of issue applies to login as to screen unlock.
There are thorny issues[*] here, but I think Will's approach is a
reasonable one for now.
[*] If you think of PAM as being a system for negotiating how to
authenticate a user, and you also think of Kerberos pre-auth in the
same way, then what we have here is a two layer negotiation, which,
like all two-layer negotiations, tends to have unsatisfactory
results and/or odd corner cases.
> >Be aware that the current OpenSolaris PAM framework typically relies on
> >the pam_authtok_get module to prompt for the password.
>
> Yea, and pam_authtok_get can accept a blank. (Solaris 10 can at least.)
> This blank is then passed along to other pam modules, The pam_krb5
> can use it to indicate if it should try a password or attempt PKINIT.
How will the user know this? If the password prompt came from
pam_krb5(5) itself (but it doesn't) then the prompt could say " (or
plugin your smartcard and enter an empty password)"; pam_authtok_get(5)
cannot possibly know to use such a prompt unless you tell it to, via a
module option, say.
The pam_authtok_get(5) concept was part of a project to: a) remove
redundant code from modules, b) get rid of the try/use_first_pass
options, c) harmonize prompting behavior.
IMO pam_authtok_get(5) should be pam_authtok_get(3PAM), kinda like we
have a [consolidation-private] pam_get_user() function, which IMO should
also be Public. (b) was a good thing, and so was (c), but (c) is
getting upset by modules that can prompt for PINs, or which can derive
PAM_USER from smartcards and/or biometrics.
Solving the multi-layer "negotiation" and other framework-level issues
is out of scope for this case though. I think Will's proposal will work
well enough for now.
> The really problem is with the PAM framework. It does not give the user any
> choice as to how the user would like to try authenticaiton. It should be
> asking as the first prompt (a list or menu) like to use a smartcard for
> local or PKINIT login, local password Kerberos password, OTP password,
> (or whatever else is available maybe fingerprint of face recognition?)
> Pam would then route to the appropriate modules, rather then starting
> a sequence of optional/required modules that may treat this as a failed
> login attempt,which can lead to locked accounts.
>
> At least pam_authtok_get should have a prompt option to tell the user what
> to do next.
I agree with your comment about the framework being the problem. The
framework doesn't deal well with the two-layer negotiation problem, and
it doesn't deal at all with asynchrony (e.g., plugin a smartcard and
have the current user/password prompt go away or change into a PIN
prompt).
I'm waiting for a code review from Gary to complete PSARC/2005/275. One
possible way to solve the multi-layer negotiation issue would be to have
pam_krb5(5) to be stacked high and call pam_eval(3PAM) (from
PSARC/2005/275) to evaluate a policy that corresponds to a pre-auth
sheme being tried.
> >OpenSolaris
> >pam_krb5 must follow this module currently as it relies on it for the
> >password. This is the reason I'm suggesting that if pam_krb5 is stacked
> >above pam_authtok_get it would assume it should try PKINT only. Given
> >this I don't seen the need for another config parameter like try_pkinit.
>
> You might be able able to drop the try_pkinit but only if the some other
> method is available to tell the differenrce between a smartcard and some
> other crypto device supported below pkcs#11.
We've talked about this as well, and I think that too is out of scope
here. But briefly, IMO there should be a way to select tokens for
C_Login() in a way that takes PAM context (e.g., PAM_TTY) into
consideration, so that only tokens that could be associated with a seat
are used. But we don't need that urgently because for SunRay the seat
is already taken into account via other methods, and for VTs we don't
care very much about this.
Nico
--
