I'm planning to file this case with PSARC next week. I'll also follow
up around the same time with a webrev. Additional materials may be
found at http://cr.grommit.com/~wesolows/smf-auth/. Comments and
suggestions welcome.
smf(5) enhancements for storage of sensitive properties
Keith M Wesolowski
14 March 2007
ident "@(#)smf-case 1.3 07/03/15 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. This
case also reserves, but does not define, the read_authorization property
for use in property groups of other types. Each string value (if any)
of this property is defined to be the name of an rbac(5) authorization
defined in auth_attr(4).
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[1] and updated[2] 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.
2.4. svccfg(1M) changes
2.4.1. export changes, introduction of exportall
'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 'svccfg exportall'. This command
behaves identically to 'export', except that the values of properties in
SPGs are exported if the user has sufficient authorization to read them.
Otherwise, 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.
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. Interface table
4.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'[3]. Given
their semantics, their presence in smf_security(5), and the probable
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.
4.2. Interfaces Imported
None.
5. References
[0] PSARC/2002/547 Greenline; see C.35, smf_security(5)
[1] Ibid., see C.10, scf_error(3SCF)
[2] PSARC/2004/525 libscf(3LIB) updates
[3] PSARC/2002/547 Greenline; see App. D
[4] Ibid., see C.6, svccfg(1M)
--
Keith M Wesolowski "Sir, we're surrounded!"
FishWorks "Excellent; we can attack in any direction!"
