=========================================================================== Inception: Per user Authentication Policy (2005/275) Submitter: Nicolas Williams Owner: Darren Moffat Interest: Nicolas.Williams@sun.com SUMMARY ======== * Advice on adding all the user_attr keys to prof_attr (except maybe for type.) * The project team will fix all nits that were brought up. ISSUES ====== eg-1 pam_eval.man, pam_user_policy.man Does "/usr/lib/security" get prepended to paths that begin with "./"? * No * The documentation doesn't actually say this... - I would just say this explicitly. * It looks to see if the first character of the path name is a "/". If it starts with a ".", it is still relative. Is there a(nother) way to test configuration files before installing them? * No, there never has been with PAM and this case doesn't change that. eg-2 PAM_POLICY both user_attr(4) and prof_attr(4) are listed in most places, but only user_attr(4) is listed in the "BACKGROUND" section. Was this an oversight, or is there something subtle here? * Neither it is just short hand. * These are nits to take care of by the project team. eg-3 pam_user_policy.man Is there always a place to prompt for PAM_USER? If there is not, what happens? * That depends on what kind of converstaiton function the application provided. There is nothing new introduced by this case. Existing modules and applications already deal with this. eg-4 pam_user_policy.man I find the "RETURN VALUES" section difficult to understand. Perhaps that's because I don't really understand PAM, but perhaps the prose could be improved as well. * I believe that if you understand PAM this is pretty clear, you can't read this man page alone you need to already understand pam(5), pam_authenticate(3pam), etc. gw-0 pam_eval: There are multiple ways a PAM stack evaluation can complete. Is it true that only if all modules return PAM_IGNORE this will return PAM_IGNORE? What about optional success and optional failure of the evaluated PAM stack, or the stack from which pam_eval is called? Is the intent of pam_eval to be a partial answer as the include flag is, or a complete answer? If it is a complete answer, I miss seeing why PAM_IGNORE should be returned. Why shouldn't the default error be returned? Then, the caller can return that as a binding service module and be done with it. If it is a partial answer, must callers of pam_eval be placed on multiple places in the initiating PAM stack to deal with the current PAM stack semantics? * I'm trying to understand the symantics of pam_eval. * It can only be called from within the process stack already. * Nicolas: pam-eval is not optional or binding - the module that calls this maybe optional or binding. It is up to the module that calls pam_eval to make sure this happens. * Glenn: I think it would help if the project team provide examples of pam_eval. * Modules today don't know about their control flag. * Gary: I believe that this works for the policy case. But I'm concerned that it is not returning the right information right now. - Darren: Maybe we should make some changes with this. gw-1 Adding to usermod/useradd and smprofile, why not also rolemod/roleadd, smuser and smrole? Adding pam_policy to smc(1M) for prof_attr only, but can also be in user_attr. * usermod/rolemod are actually same source/binary so yes it is added there. smuser/smrole should be updated as well. gw-2 pam_user_policy: Should define the service module entry points and how each functions. For example The pam_use_policy module implements all the PAM service module functions and .... For a specific type, such as pam_sm_authenticate, it may discuss getting PAM_USER if not set. Why does pam_policy return PAM_IGNORE for calls other than pam_sm_authenticate() if PAM_USER is not set? Doesn't pam_policy also apply elsewhere? How is passwd handled with respect to prompting for PAM_USER, there's a pam_passwd_auth(5) module, will this be stacked above it? What are the implications for pam_smartcard(5)? Would pam_jcdi(5) be any different? What are the implications for pam_sunray? * pam_smartcard does not and never has supported password change. For now pam_jcdi(5) isn't being shipped the project was cancelled. This project doesn't changing anything for those modules though. They never were in the default stack anyway. As for pam_sunray - well we don't really know what it does because it was never ARC'd. There are no config files shipped with this case that include pam_jcdi or pam_sunray because they are not part of Solaris. As for pam_smartcard it isn't in any of the default configs included in this case because it requires significant admin setup for smartcard. pam_smartcard is also a useless toy and we may be annoucing EOF of it soon (but less not have that discussion here). The way it gets placed into the pam.conf today is to insert it at the top of the stack for dtlogin/dtsession/xscreensaver/xlock the smartcard(1m) command does that and it will still work today and in the future if pam_user_policy is in the default pam.conf. * Gary: We really need to communicate with Sunray on this issue as well. gw-2 (con't) Returning the default error if pam_eval returns PAM_IGNORE seems to require knowledge of the default values that knowledge is presently only coded into libpam. This seems like an obvious place to get out of sync. See gw-0. * pam_deny PSARC/2004/290 does that today. gw-3 Why shouldn't there be a policy.conf default for pam_policy key? That way admins don't need to try to merge one of the proposed *.conf files into the local pam.conf and the *.conf files can be replaced on upgrade should changes be necessary. * policy.conf doesn't scale it should have been in the nameserice. You also don't need a pam_policy key in policy.conf because that only provides the default and we already have that its call /etc/pam.conf * Gary: i think it's wrong to have to edit pam.conf but I don't think it'll hold up the case. gw-4 Why do the *.conf files need ".conf"? Perhaps, we could come up with more approachable names. * conistency with /etc/pam.conf and with the include case. Also if we ever introduce /etc/pam.d like Linux has (and I believe we need to) then we need a way to distinguish the two styles because the pam.conf syntax isn't structured enough to tell the two appart in some cases. * Gary: I still think it is icky naming. * This issue will be taken offline and discussed even more. Missing documentation for common-interactive, common-login, common-non-interactive, ksvcs. What's their interface taxonomy? It is really "pam_policy" or should it be "auth_policy" or "account_policy"? * It is in the case material: INTERFACE STABILITY AND RELEASE BINDINGS ---------------------------------------- Interface Stability Release Binding pam_eval(3PAM) Stable Minor/patch pam_user_policy(5) Stable Minor/patch config file names Stable Minor/patch config file semantics Stable Minor/patch config file contents Unstable Minor/patch It is really "pam_policy" or should it be "auth_policy" or "account_policy"? * Any of those would do, however the word pam is in there because this only applies with PAM and not with GSS or SASL. * Gary: In the man page, you list the stability of all these things but I think this is the wrong place to have them. - This should be left to the tech writer then, since it doesn't deal with the actual arch structure. gw-5 UIRB? * Review of what? * Darren: Does the ARC really believe that this will help if this is sent to UIRB for review? - I think everyone agrees that this can be done as a self review. gw-6 NITs: prof_attr.4.diffs: pam_policy is described in user_attr(4) and pam_user_policy(5). Please describe completely in only one place. Don't split the description across man pages. missing *.conf man pages pam_eval.man: DESCRIPTION pam_eval() evaluates the current service and module type entries from conf_path and evaluates the PAM stack defined there. conf_path has the same format as pam_conf(4). If the path name is not absolute, it is assumed to be relative to /usr/lib/security. . . . RETURN VALUES pam_eval() returns the PAM return code produced by evaluating the PAM stack's service modules. pam_user_policy.man: Should also say something like: "pam_policy() implements all the PAM service module functions. ..." "pam_sm_authenticate() calls pam_get_user() with the default prompt to get the value of PAM_USER. ... " What options does this module take? Please have a ``debug'' option. Interface Stability *.conf really seems to belong on their individual man pages. gw-7 TCA add all the user_attr keys to prof_attr (except maybe for type.) Add new function char *getuservalue(const char *keyname, const char *username) to libsecdb to walk the user_attr, prof_attr and policy.conf databases (file) to extract the value for a given keyname. * Not this case this needs much more design than this. * Darren: I don't think this should be a TCA - I think that this is more advice. Update smc(1M) for all user_attr keys in prof_attr * Why should this case be burdened with the sloppy work of previous ones that didn't update smc(1m) ? gw-8 SC/PAC advice, do something positive about providing an extensible interface for extended user attributes (in such a way as to be sustainable and avoid train wrecks). See also: 6255542 "Lack of staffing inhibits innovation in user extended attributes" * Which is exactly why I'm saying that the suggested TCA in gw-7 is not appropriate for this case. Advice is appropriate. Whats more we still need direction from the Solaris PAC on what our Solaris management interface is supposed to be. wes-1 "krb5.conf" name collides in its leaf name with file used to configure kerberos itself. suggest naming the files in /usr/lib/security as pam-krb5.conf, pam-foo.conf, etc. * This issue has been discussed above already. wes-2 RBACTrainWreck: use of "keys" here is ambiguous/confusing. it looks like the only true lookup key for the user_attr database as a whole is the user login name, and the other things referred to as "keys" are per-user named attributes. (it may be consistent with the *_attr documentation but is inconsistent with the common use of "key" and thus a definition would be helpful) * BillS: This is just a writing suggestion. - This will be cleared up in the next review. NEXT STEP ========= * The project team will go back and resolve any issues/recommendations that were brought up during today's review.