Subject: Defining Workstation Owner Infrastructure [PSARC/2008/034 FastTrack timeout 01/23/2008] To: psarc-ext@sun.com PSARC-record@sac.sfbay.sun.com Cc: lsarc@sac.eng, Riny.Qian@sun.com Bcc: one-pager-list@sac.sfbay one-pager-log@sac.sfbay sac-bar@sac.sfbay I'm self sponsoring this case. It requests a Patch release binding and a Committed interface Taxonomy. Full diff marked man pages for policy.conf(4) and chkauthattr(3secdb) are in the case directory. pfexec(1), sys-suspend(1M), getexecuser(3secdb), user_attr(4) are unmodified and included for reference. I apologize for the length, and felt the background, case bounds and relationship with virtal consoles details would be helpful to the understanding. The timer is set for 23 Jan. 2008. Gary.. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Background: =========== The legacy concept of a "workstation owner" exists in sys-suspend and /etc/default/sys-suspend which delivers with PERMS=console-owner. That legacy defines whomever is logged in on /dev/console as being permitted to execute /usr/openwin/bin/sys-suspend which in GUI mode will present a "suspend"/"shutdown"/"cancel" menu and in non-GUI mode just do the action requested without confirmation (as I found out on my test machine moments ago, now being power cycled to come back to life ;-). Execution Profiles for Restricted Environments [PSARC/1997/332] established the Solaris Role Based Access Control (RBAC) infrastructure of Rights Profiles, Authorizations, Execution Profiles, and roles. 1997/332 provided for granting users "rights" beyond what they would have had previously base on their userID. It also provided for roles that could be granted to users and the ability for a granted user to extend "rights" by "entering" (su(1M)) a role. Neither of these mechanisms provides for a user to "automatically" some times have "rights" and sometime not have those rights. The project team (me) has recently been involved in various discussions on how to control access to such things as WiFi configurations, Gnome Power Management [LSARC/2007/702], GNOME Power Management Support [PSARC/2008/021]. Other applicable areas could include things a workstation or laptop "owner" might just expect to do. However, granting "normal users" these rights in all situations is likely to be undesirable. Having "normal users" enter roles to gain this class of rights makes desktop tools more complicated. Rights Profiles are "hierarchical": that is they can contain other Rights Profiles in addition to authorizations and commands. Case Bounds: =========== The pre-review discussion wondered far and wide, so I'd like to say what this project is not and set the expectations of its scope: The project team is agnostic with respect to the possible set of terms used to instantiate the elements of this project, as long as they are parallel and imply owership rather than casual use. The project choose Workstation Owner because that was a term that had been used in conversation. System Owner, Machine Owner, and other terms seem equally agreeable. This project has nothing to do with logindevperm device processing (beyond that the login device owner set to the login user). This project has nothing to do with how printers, USB devices, audio, flash memory, etc. is associated with a user/process. This project has nothing to do with how the preceding moves around in the face of Virtual Consoles [PSARC/2006/591]. This project is independent of the current (CDE and likely obsoleted) sys-suspend command or configuration. This project makes no API changes to existing interfaces. This project does not populate the Workstation Owner Rights Profile (other projects, such as NWAM and Power Management need to submit cases to populate the Workstation Owner Rights Profile). The bounds of this case are to: 1) define the concept of a "workstation owner", 2) define the mechanism (an automatically assigned Rights Profile) for granting the workstation owner additional "Rights" than that user would have if not granted by user_attr(4), policy.conf(4). 3) define a "Workstation Owner" Rights Profile name (in prof_attr(4)) with "empty" contents, for others to populate. Proposal: ========= Define an infrastructure for automatically granting additional Rights Profiles to users who are identified as the "owner" of a Solaris workstation (or laptop). Define the "workstation owner" to be owner of the "/dev/console" device as set by the various login applications through di_devperm_login(), Interface for Enforcing /etc/logindevperm [PSARC/2003/612]. Note for Virtual Console [PSARC/2006/591], the owner of "/dev/console" is defined as "the first logged in user on the consoles" /dev/vt[1-6] the serial line virtual consoles. As 2006/591 has not yet delivered and when delivered isn't enabled by default, this project team intends to work with the Virtual Console project team, Riny Qian, Cc-ed here to determine if there are additional interfaces needed to define "workstation owner". A preliminary thought might be a property in the virtual console service manifest to specify a graphical vt as the "owner" if "/dev/console" was un-owned (i.e., root as is the case for sys-suspend(1M)). Details: ======== Add a key=value, "WORKSTATION_OWNER=", to policy.conf(4) which defines the name of the workstation owner Rights Profile. If present, the value is interpreted as a list of Rights Profiles to be granted to the "workstation owner". Adding a key=value allow the admin the ability to disable the feature if that is desired. Modify chkauthattr(3secdb) to process Rights Profiles to include processing the WORKSTATION_OWNER if the user is the workstation owner. chkauthattr() takes an authorization name (such as "solaris.admin.printer") and a user name (such as "gww") and returns whether the user is granted that authorization, from either the AUTHS_GRANTED= list of authorizations, the PROFS_GRANTED= (and from this proposal, the WORKSTATION_OWNER=) list of profiles found in policy.conf(4), or the list of authorizations and profiles found for that user in user_attr(4). The WORKSTATION_OWNER list of Rights Profiles is inserted between the list directly granted to the user (via user_attr(4)) and the existing policy.conf(4) "PROFS_GRANTED=" list. The list is inserted there rather than appended because pfexec(1) stops at first match and by default the PROFS_GRANTED list is "Basic Solaris User" whose default profiles list consists singly of "All" which consists of a single command wild card. pfexec(1) stops at first match, so having the All profile before any other profile stops searching for commands. Modify pfexec(1) -- really getexecuser(3secdb) -- to search the WORKSTATION_OWNER Rights Profile list before searching any other if the calling user is the workstation owner. Define an empty "Workstation Owner" Rights Profile for other projects to populate. Deliver the WORKSTATION_OWNER policy.conf(4) entry defined to be the Workstation Owner Rights Profile (WORKSTATION_OWNER=Workstation Owner). On upgrade add "WORKSTATION_OWNER=Workstation Owner" if there is no WORKSTATION_OWNER. This follows the practice of AUTHS_GRANTED and PROFS_GRANTED. Note: the non "console-owner" configurations in /etc/default/sys-suspend, "all, "-", "" are all covered by the existing RBAC infrastructure. For "all", configure policy.conf(4) PROFS_GRANTED key to include the "Workstation Owner" Rights Profile; for "-" (none), comment out or remove the policy.conf(4) WORKSTATION_OWNER key; for "", configure user_attr(4) for the enumerated users to include the "Workstation Owner" Rights Profile in their list of Rights Profiles. policy.conf(4): DESCRIPTION The policy.conf file provides the security policy configura- tion for user-level attributes. Each entry consists of a key/value pair in the form: key=value The following keys are defined: PROFS_GRANTED Specify the default set of profiles granted to all users. This entry is interpreted by chkauthattr(3secdb) and getexecuser(3secdb). The value is one or more comma-separated profiles defined in prof_attr(4). + WORKSTATION_OWNER + Specify an additional default set of profiles granted to + the "workstation owner" user. This entry is interpreted + by chkauthattr(3secdb) and getexecuser(3secdb). The + value is one or more comma-separated profiles defined + in prof_attr(4). PRIV_DEFAULT and PRIV_LIMIT Settings for these keys determine the default privileges +NOTES + The "workstation owner" is defined as the owner of \fI/dev/console\fP. chkauthattr(3secdb): SYNOPSIS int chkauthattr(const char *authname, const char *username); DESCRIPTION The chkauthattr() function verifies whether or not a user has a given authorization. It first reads the AUTHS_GRANTED key in the /etc/security/policy.conf file and returns 1 if it finds a match for the given authorization. If chkau- | thattr() does not find a match, + if the \fIusername\fP is the + name of the "workstation owner", it reads the WORKSTATION_OWNER + key in /etc/security/policy.conf and return 1 if the given + authorization is in any of the profiles specified in the + WORKSTATION_OWNER keyword, then it reads the PROFS_GRANTED key in /etc/security/policy.conf and returns 1 if the given authorization is in any profiles specified with the PROFS_GRANTED keyword. If a match is not found from the default authorizations and default profiles, chkauthattr() reads the user_attr(4) database. If it does not find a match in user_attr, it reads the prof_attr(4) database, using the list of profiles assigned to the user, and checks if any of the profiles assigned to the user has the given authoriza- tion. The chkauthattr() function returns 0 if it does not find a match in any of the three sources. A user is considered to have been assigned an authorization if either of the following are true: o The authorization name matches exactly any authori- zation assigned in the user_attr or prof_attr databases (authorization names are case-sensitive). o The authorization name suffix is not the key word grant and the authorization name matches any authorization up to the asterisk (*) character assigned in the user_attr or prof_attr databases. +NOTES + The "workstation owner" is defined as the owner of \fI/dev/console\fP.