(re-sending to the open alias)
I'm sponsoring the following fast track for Keith Wesolowski.
The case seeks binding for a Micro/Patch release (i.e. a Solaris Update).
The timer is set for March 30. The case spec is below and a copy
is in the inception.materials/ directory. Also found in the
materials directory are diffs to all relevant SMF man pages.
-Mike
--8<--
smf(5) enhancements for storage of sensitive properties
Keith M Wesolowski
14 March 2007
ident "@(#)smf-case 1.6 07/03/21 SMI"
1. Description
This case describes a set of modifications to svc.configd(1M) and
related administrative tools to support storage of, and restriction of
access to, sensitive application properties such as passwords. This
case seeks Micro/Patch Release binding.
2. Discussion
2.1. The read_authorization property
Currently, creation, modification, and deletion of property groups
and properties is permitted only to client processes with the full set
of effective privileges. In addition, processes with certain RBAC
authorizations are permitted to change repository contents under certain
circumstances. Finally, smf permits the addition of arbitrary
authorizations to perform these actions on a per-property group
basis[0]. All properties in all property groups may be read by
any process. This case introduces read_authorization as an analogue
to the existing value_authorization and modify_authorization properties.
2.1.1. Definition
The read_authorization property may optionally be added to any
property group of type application (SCF_GROUP_APPLICATION). It is
defined to be a string-valued property with zero or more values. Each
string value (if any) of this property will be interpreted as the name
of an rbac(5) authorization defined in auth_attr(4). A
read_authorization property which is not string-valued will not be
interpreted specially.
Property groups of types framework, method, and dependency describe
the state and configuration of the service or instance with respect to
SMF itself. Because properties in these groups have specific
well-defined effects on the behaviour of SMF, any mechanism which may
render any combination of these properties invisible may have complex
side effects. Because the schemas of these groups are already
well-defined and none of the data they contain is sensitive, there is no
reason to address the complex failure semantics associated with read
access controls on these group types. Therefore, this case reserves,
but does not define, the behaviour of the 'read_authorization' property
with respect to these group types. Future enhancements such as
templates[1] are expected to permit finer-grained control over the
meaning of this and similar properties within a particular group.
2.1.2. svc.configd(1M) RPC changes
Property create, modify, and delete semantics are not modified by
this case, nor are create and delete semantics of property groups. Read
semantics are unchanged with respect to properties in property groups
which do not contain a string-valued read_authorization property. Those
property groups which do contain this property, even if it has no values,
are referred to herein as sensitive property groups (SPGs). The
behaviour observed by clients attempting to obtain the value(s) of a
property in a SPG will be as follows:
- If the requesting client would be permitted to modify the property,
it will be permitted to read the value(s); otherwise,
- If the requesting client has one or more of the authorizations
named by the 'read_authorization' property in the same SPG, it will
be permitted to read the value(s); otherwise,
- The requesting client will not be permitted to read the value(s)
and will receive the REP_PROTOCOL_FAIL_PERMISSION_DENIED error
code.
While the client cannot distinguish between failure due to
locally-enforced policy and backend-enforced policy (in the networked
repository case), this shortcoming also exists with respect to the
existing add/modify/delete policies. This case does not attempt to
address this deficiency.
2.2. libscf(3LIB) changes
libscf(3LIB), as originally defined[2] and updated[3] already
provides an appropriate error code for use by clients when the contacted
svc.configd(1M) denies permission to perform the requested operation.
This case extends the use of that error code to the cases listed in
2.1.2 above.
The following functions will fail and set the libscf(3LIB) error
value for the calling thread to SCF_ERROR_PERMISSION_DENIED if the
contacted svc.configd(1M) returns an error code of
REP_PROTOCOL_FAIL_PERMISSION_DENIED in response:
scf_property_get_value
scf_iter_next_value
2.3. svcprop(1) changes
With respect to SPGs, svcprop(1)'s behaviour is modified as follows:
- If a property or property group was explicitly specified with -p,
and svc.configd(1M) denies access to the values of the specified
property/ies, svcprop(1) will abort and, unless the '-q' option was
provided, display an error message.
- If no property or property group was specified, properties for
which the user lacks appropriate authorization to read will be
displayed as if they had zero values (the present behaviour is to
display the empty string for the value of such properties).
2.4. svccfg(1M) changes
2.4.1. export changes, introduction of export -a
'svccfg export' is modified to export the values of properties in
SPGs as if they had no values, regardless of whether the user performing
the operation has the required authorization. This prevents accidental
exposure of sensitive data in XML documents used for interchange
purposes.
To provide the ability to export documents containing the values of
sensitive properties, we introduce the '-a' option to the export
subcommand. With this option, 'export' will export all properties in
SPGs if the user has sufficient authorization to read them. Otherwise,
upon encountering a property which cannot be read due to access
controls, the command terminates and displays an appropriate error
message.
2.4.2. archive changes
The purpose of the 'archive' subcommand is to dump the entire
repository in a format "suitable for a relocatable repository
backup"[4]. In the presence of SPGs, this effectively requires that the
user executing the command have sufficient authorization to read all
values of all properties, else the archive will be incomplete.
Accordingly, this subcommand will fail and display an error message if a
property value cannot be read.
2.5. auditing
An AUE_smf_read_prop audit record will be generated when an attempt
is made to read properties in SPGs. This record will contain the FMRI
of the property being read and the status (success or failure) of the
attempt to read it, as well as the authorization used (if successful) or
the most specific authorization that would have been required (if
unsuccessful) to read the value.
3. Manual page changes
Diffs to relevant manual pages are included in the case materials. Modified
man pages are:
svcprop(1)
svccfg(1M)
scf_property_create(3SCF)
scf_iter_create(3SCF)
smf_security(5)
4. SMF policy changes
This section details changes required to the 'Service Management
Facility (SMF) usage' policy[5].
4.1. Guidance
The third bulleted item in 'Guidance for Delivery of SMF Services'
currently reads:
# Services must provide service related RBAC authorizations, as
# appropriate, by providing service specific values for the
# action_authorization, modify_authorization and
# value_authorization of property groups. See smf_security(5).
# These authorizations must follow the form of
# "solaris.smf.{manage, modify, value}." respectively. These
# authorizations must be delivered into an appropriate Rights
# profile, either new or existing.
This guidance shall be altered to read:
# Services must provide service related RBAC authorizations, as
# appropriate, by providing service specific values for the
| action_authorization, modify_authorization,
| value_authorization, and read_authorization of property
| groups. See smf_security(5). These authorizations must follow
| the form of
| "solaris.smf.{manage, modify, value, read}.<token>,"
# respectively. These authorizations must be delivered into an
# appropriate Rights profile, either new or existing.
4.2. Appendix B
Appendix B currently reads:
# It should be noted that configuration data residing in the SCF
# repository is world-readable. Projects with configuration data
# that is deemed sensitive in nature or that should remain
# private from a security standpoint must consult with the ARC
# to determine if the Service Configuration Facility is the
# appropriate repository for their data.
With the implementation of the changes specified above, this guidance
is no longer correct. It shall be amended to read as follows:
# It should be noted that configuration data residing in the SCF
| repository is world-readable by default. Projects with
| configuration data that is deemed sensitive in nature or that
| should remain private from a security standpoint must consult
| with the ARC to determine if the Service Configuration
| Facility is the appropriate repository for their data. If so,
| the property group(s) intended to contain sensitive data must
| be defined in manifests with an appropriate read_authorization
| property (see smf_security(5)), and no sensitive information
| may be delivered in the manifest itself.
5. Interface table
5.1. Interfaces Exported
Well-known property 'read_authorization' Committed
No case explicitly defines the commitment level of the well-known
properties 'modify_authorization' and 'value_authorization'[6]. Given
their semantics, their presence in smf_security(5), and the clear
intent that they be introduced as Evolving, this case also clarifies
them as follows:
Well-known property 'modify_authorization' Committed
Well-known property 'value_authorization' Committed
The intent of this case is that 'read_authorization' be a peer of
these existing well-known properties and therefore have the same
commitment level.
5.2. Interfaces Imported
None.
6. References
[0] PSARC/2002/547 Greenline; see C.35, smf_security(5)
[1] http://www.opensolaris.org/os/project/vpanels/templates/
[2] PSARC/2002/547 Greenline; see C.10, scf_error(3SCF)
[3] PSARC/2004/525 libscf(3LIB) updates
[4] Ibid.; see C.6, svccfg(1M)
[5] http://www.opensolaris.org/os/community/arc/policies/SMF-policy/
[6] PSARC/2002/547 Greenline; see App. D
--
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
