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, "-", "<user1, ...>" 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 "<user1, ...>", 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.
