IAM ====== Name: Credential Process Groups (CPGS) Submitter: Nicolas Williams Owner: Garrett D'Amore Interest: darren.moffat@sun.com, nicolas.williams@sun.com Status: inception scheduled 05/06/2009 Exposure: open Comment: SUMMARY ======= Today the Solaris NFS client can only associate cryptographic credentials with all of each users' processes. Other operating systems can associate cryptographic credentials with users' login sessions, which is desirable in some cases and trivially enables destruction of cryptographic credentials when the last reference vanishes. Our solution is based on grouping processes through cred_t, with an extensible notion of process groups. This solution is generic generic and will enable solutions to other problems as described below. ISSUES ====== PSARC 2009/271: Credential Process Groups (CPGS) Submitter: Nicolas Williams Owner: Garrett D'Amore Issues for inception (05/06/2009): gw-0 A little more overview please. A simple worked example. A number of claims of simplicity are made particularly WRT application transparency, audio, device tracking, type registration. Of the many possibilities, what is being implemented in this phase? What types are being delivered? A Needs more documentation gw-1 20q-3 Don't forget to review the audit requirements for the new system calls. gw-2 20q-9 I would think all the services would be distributed disabled. Any that are required for all system configurations would be enabled in the generic SMF profile. Any that are required only when a subsystem is enabled, such as, krb5, would be enabled/disabled as part of that subsystem (kclient). Any that are not required to be always enabled would have appropriate solaris.smf.manage. authorizations which would be part of the Rights Profile that supports the feature enabling/configuration, such as, Kerberos Client Management. gw-3 I found the security model details hard to follow from the materials. Please say more. secret/private, register/unregister, what is per-zone / vs global zone, per type flag semantics. gw-4 PAM service modules do not make decisions based on service name. Services may have separate PAM stacks to distinguish their policies. login types call PAM_ESTABLISH_CRED; su calls PAM_REINITIALIZE_CRED. gw-4a It would seem a model (and perhaps names) of ESTABLISH, REINITIALIZE, REFRESH, DELETE like pam_setcred() would be meaningful. gw-5 Overview(s). How are delayed execution jobs kerberos credentials affected? gw-6 Overview "FGAP". Can CPGs also apply to "FMAC" Security Contexts? gw-7 Overview how do di_logindevperm_login()/logout() play into things. login types call di_logindevperm_login(). The logout reaper calls di_logindevperm_logout(). gw-8 cpg(1) output not an interface? gw-9 cpg_change(2). Why is CPG_ALL partial success semantics OK? Is it idempotent? Why is cpg_change_to() restricted to only one change? (or why doesn't atomic change all make sense?) Overloading proc_audit shouldn't be done. If the audit subsystem is converted to use cpgs, then the use of proc_audit is appropriate, otherwise it is not. What is the use of the *AUDIT* flags outside the audit subsystem? If audit is not being converted as part of this project, the term *AUDIT* does not seem appropriate. New flags can always be added (presuming enough bits ;-). See 4a for cpg_change() flag names. What is the default value of ncpgroups_max? gww-99 Nits- see me offline for some typos and other materials nits. jdc-1 If PAM (and login sessions) are the main CPG setting point, who sets the CPG for a cron job? Or do cron jobs not have CPGs? (If they don't, then how does AFS work with cron?) jdc-2 What would happen to the interfaces defined if we needed a different CPG granularity? (E.g., per-user rather than per-session.) What does "emulation" mean here? jdc-3 What privileges are required to create a CPG, set its contents, assign it to a process, or read the data back? (How do CPGs interact with LP?) jdc-4 Where is the name space for cpg_type_reg defined? How do we avoid conflicting uses? Are there any naming conventions here? (E.g., "com.sun.name..." or "SUNW,name...") jdc-5 Are there new dtrace probes associated with CPGs? jdc-6 Why would a CPG ID be secret? Isn't it just a number? jdc-7 CPG_F_LOGIN_W_SEAT and CPG_S_CHG_AT_LOGIN_W_SEAT feel like part of an extensible broader idea; a "class" of CPG. jdc-8 Why is ncpgroups_max needed? This sounds like a resource control, but is a retro /etc/system variable. ram-1 Is any privledge required to create a CPG type? Are there limits on the name length? ram-2 Could a rogue process (assuming no special privledge required) claim all available types (ncpgroups_max)? Could some denial of service result? ram-3 Nit: names _CONFIG_NCPGROUPS and ncpgroups_max don't seem to reflect the "number of types" nature of the limit. ram-4 In PAGS.txt, you mention that an OpenAFS client in Solaris emulates PAGs. Should/ would this be converted to use CPGs? dik-1 Where the changes to /proc? You cannot modify "ptools" without having the properties available through /proc. dik-2 How are the CPGs recorded in a core dump? dik-3 How are the CPGs shown through pcred? Does that work in a core dump? dik-4 What happens when a user su(1)s to root and then starts a daemon? dik-5 When this project is completed, which consumer will be putback with this? boyd-1 I don't see any mention in the case materials of new fields for ps. Personally, I'd really like to see something like -o cpg fiveash-1 - svc:/system/cpg/krb5:default registers the "krb5" CPG type and runs a daemon to kdestroy Kerberos V credentials when the last reference to a CPG vanishes. How does this interact with svc:/network/security/ktkt_warn? Seems to me that there should be one service tending to the needs of the krb5 related ccache. Perhaps the function of ktkt_warn can be folded into svc:/system/cpg/krb5? hahn-1 What are the default registered CPG types on a newly booted system? (Are there CPG types created by the kernel prior to the creation of init(1M)?) If the kernel does create such types, how do they participate in the "resource release at empty" operation? hahn-2 Why 64-bit IDs, and not reuse of id_t and idtype_t? (Unusual for a process collective.) hahn-3 What is the complete list of system calls that cause a CPG to change its settings? For instance, should setuid(2) or setppriv(2) calls also have CPG_F_* flags? hahn-4 There's no new privilege needed for CPG type registration or removal? What privilege is required? hahn-5 Do you expect the behaviour of a cpg_type_unreg() call to be blocking--destroying all CPGs of that type--or merely allow those CPGs to linger until all processes have exited. What happens to CPGs with door calls in the _unreg() case? hahn-6 It would be helpful to see the Boomer example explained a bit, if any preliminary sketch is available. (My feeling is that there's a lot of public mechanism for one consumer.) hahn-7 Usually the zone/project/task/process resource controls need to be transferred in the attributes of the work unit of whatever subsystem is taking the request out of process context but, if you've worked out more about subsuming those attributes, I'd be interested in seeing the details. hahn-8 Could the project team comment when they expect a new feature should introduce a CPG type, rather than a process privilege? It might also be useful to understand how CPGs might be used to implement a concept like a security label, as in classic Trusted Solaris? I suppose I'm looking for early advice about how to design using this feature. (For instance, if the answer to 1/1' is "no", then does that imply kernel features must introduce privileges?) edp-1 You repeatedly state that CPGs are associated with login sessions. Please define a login session in the CPG context and provide examples. A login session is the set of processes running as the PAM_USER that result from a successful attempt to login, whether on console, via ssh, etc... Two concurrent logins by the same user on the same host would be two different login sessions -- they'd have different CPG IDs for the various CPG types. edp-2 You also mention that CPGs will help with obtaining credentials for cron jobs, which specifically don't have a login session (as i understand login sessions), so please explain how this works. Yes, I did not flesh that out. That was an indirect reference to a problem in Solaris Kerberos where all processes running as a user must share the same Kerberos credentials because the only way that the Kerberos credentials can be found by the secure NFS client right now is by referencing the euid of the process that's causing an NFS RPC. Solaris Kerberos right now does nothing to reference count the Kerberos credentials cache of a user, which causes a variety of problems. The cron angle is somewhat indirect, and really will require a way to make Kerberos credentials available to cron for later use, so I should not have mentioned cron except as a future beneficiary of this project. edp-3 You mention that CPGs are bound to credentials (there seems to be a 1:1 mapping), but in my gdm login session, different xterms have different cred_t pointers. so will different xterms have different CPGs? (once again, perhaps this confusion results from my lack of understanding of how "login sessions" are defined wrt CPGs.) A process' cred_t changes when a setuid/setgid program is executed, even if in the end (that is, after the app drops privs) that process' cred_t ends up looking just like its parent. CPG membership is inheritted across all system calls that change a cred_t OTHER THAN cpg_change(2) and cpg_change_to(2). That is, CPG membership changes are always explicit, though because most often only login apps/PAM modules will call cpg_change(2) users will not have to take explicit steps w.r.t. CPG membership. (AFS users will often take explicit steps to change CPG membership, as they do today with the pagsh(1) command -- see the manpage reference in the AFS readme in the case materials. But that's entirely optional.) edp-4 group membership is represented in cred_t. does this impact cred_t comparisons? (ala crcmp()). Yes, it does. See the cpg_change manpage in the case materials, specifically this: CPG_S_DISTINGUISH_CRED Processes with process credentials that differ only with respect to membership in CPGs whose semantics include this flag will be treated as having distinct process credentials by the kernel private function crcmp(). edp-5 why must CPGs IDs be unique (since boot)? Because it will be useful for projects that want a cheap way to do access control and revocation. See my reply to Stephen Hahn on this point. edp-6 why isn't ps(1) being modified to display the CPGs ID? Because I hadn't thought of it, or how to do it. However last night I thought of a way: add columns named cpgid- and cpgudata- whose values will be CPG IDs and CPG user data for CPGs of the given type. THE NEXT STEP ============= Inception review