Issues for inception: Per user Authentication Policy (2005/275) 18 May 2005 File Version: 1.6 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ eg-1 pam_eval.man, pam_user_policy.man Does "/usr/lib/security" get prepended to paths that begin with "./"? Is there a(nother) way to test configuration files before installing them? 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? eg-3 pam_user_policy.man Is there always a place to prompt for PAM_USER? If there is not, what happens? 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. 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? 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. 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? 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. 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. gw-4 Why do the *.conf files need ".conf"? Perhaps, we could come up with more approachable names. 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"? gw-5 UIRB? 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. Update smc(1M) for all user_attr keys in prof_attr 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" 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. 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) Issues for Commitment: Per user Authentication Policy (2005/275) 1 Feb 2006 File Version: 1.6 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ gw-1 Question to the members: do the SMC changes require a UIRB review? LSARC and UIRB in the past have dealt with SMC. gw-1a Perhaps something richer than just a type in would be desirable. For example could there be a list constructed from /usr/lib/security as well as a type in? Could there be some validation that a typed in PAM policy file does exist? gw-2 pam_user_policy, more for the case that makes this go live, just wondering should there be some backup default (viz: /usr/lib/security/unix) if policy not found. This may be helpful in protecting against admin failures. I agree that PAM_SYSTEM_ERR is the right thing to return for administrative errors it's returned for not finding a conf file. gw-3 user_policy: probably a nit, some of the ``files'' need to consider things like unix_cred, unix_session, authtok*. gw-4 Nit: pam_eval/pam_user_policy perhaps more info relative to stacking of modules as "optional" if in the middle of the stack would be helpful. gw-5 Nit: I have a number of non-architectural updates for pam_user_policy. gw-6 Rampart memorial question -- this time relates to SMC