.de Sc
\\s-1\\$1\\s0\\$2
..
.ds cA 2007/177
.ds aR \s-1PSARC\s0
.LP
.so ../../amac
.Co
.ds LF \fI\*(aR/\*(cA\fP
.ds RF \fICopyright 2007 Sun Microsystems\fP
.if n .ds CF
.IP \fBSubject:\fP 15
SMF Read-protected Property Storage
.IP "\fBSubmitted by:\fP" 15
Keith Wesoloski
.IP \fBFile:\fP 15
\*(aR/\*(cA/opinion.ms
.IP \fBDate:\fP 15
August 1st, 2007
.IP "\fBCommittee:\fP" 15
Bill Sommerfeld,
Mark Carlson,
James D Carlson,
Gary Winiger.
.IP "\fBProduct Approval Committee:\fP" 15

Solaris PAC
.br
solaris-pac-opinion@sun.com
.pn 2
.NH
Summary
.LP
The project proposes to extend the access control facility for SMF
properties to allow read access to property groups to be restricted to
processes in possession of specific RBAC authorizations.
.NH
Decision & Precedence Information
.LP
The project is approved as specified in reference [1], but as modified
by the required technical changes listed in Appendix A below.
.LP
The project may be delivered in a patch release of the ON consolidation.
.LP
The project depends on the following other project and may not be
delivered before it:
.RS
.IP 6546699 8n 
svccfg archive should be able to be reimported
.RE
.NH
Interfaces
.LP
The project exports the following interfaces.
.if n .ne 8
.if t .ne 3
.TS H
box;
c s s
l | l | l.
Interfaces Exported
_
Interface	Classification	Comments
_
.TH
read_authorization	Committed	T{
SMF Property; new with this project
T}
modify_authorization	Committed	T{
SMF Property; revision of prior Evolving
T}
value_authorization	Committed	T{
SMF Property; revision of prior Evolving
T}
svccfg export -a	Committed	T{
Includes read-protected properties.
T}
svccfg archive -a	Committed	T{
Includes read-protected properties.
T}
svccfg import	Committed	T{
All imported property changes become visible simultaneously.
(See below)
T}
.TE
.NH
Opinion
.LP
This project was originally titled "SMF Sensitive Property Storage".
The committee felt it was appropriate to include a mechanism within
SMF to allow properties to be read-protected.  There was, however,
significant difficulty with the assertion by the project team that
this mechanism is sufficient for storage of sensitive
security-critical values such as passwords and keys.  The proposal
includes only a read-protection facility based on authorizations; it
does not include any additional protections.
The primary architectural question before us is whether SMF is the
right home for such parameters, and if so, where additional
protections belong -- should they live above, or below, the SMF
property interface.  
.NH 2
Background
.LP
First, it's worth noting that when examining system security, it is
necessary to look across layers at relevant implementation details;
in short, it's necessary to get all the details right.  This goes
against many otherwise well-founded instincts favoring trusting
abstrations to deliver what they've committed to deliver.
.LP
General purpose computer systems provide a regrettably poor
environment for the protection of small sensitive items such as keys
or passwords.  Each additional copy of a sensitive value represents an
additional opportunity for the value to leak; each additional
component or layer with access to a sensitive value increases the
risk that a bug or misconfiguration may expose the value.
.LP
The FIPS 140-2 specification for cryptographic modules[3] defines a
concept known as a "Critical Security Parameter" as: "security-related
information (e.g., secret and private cryptographic keys, and
authentication data such as passwords and PINs) whose disclosure or
modification can compromise the security of a cryptographic module."
If we replace "cryptographic module" with "system", we can apply this
term more broadly to Solaris, as this term would appear to cover many
properties which service developers may wish to store.  These
properties tend to be both small, and changeable; the actual value
stored matters less than the fact that two or more communicating
principals share the same value.
.NH 2
Applicable Best Practices
.LP
Many of the recommendations found in existing "Storing Reusable
Passwords on a Filesystem" Best Practice [2] appears to apply to uses
of this facility as well.  The best practice recommends that, in
addition to the use of file permissions, additional protections be
used where applicable.  For instance:
.RS
"... it is recommended that the actual reusable password should
be stored on the filesystem in either an encrypted or obfuscated
format in order to help prevent against accidental disclosure."
.LP
"... In the case where a single program must store and protect a
variety of reusable passwords, consider the use of a master passphrase
that is used by the program to encrypt and decrypt the password
store."
.RE
Unfortunately the text is focussed around interactive application
considerations; many of the recommendations contain aspects that are
not directly applicable to system components like SMF; some revision
to the document seems to be called for to clearly show applicability
of these concepts to system components.
.NH 2
Existing Practice
.LP
Many existing subsystems within Solaris store critical security
parameters separately from other configuration parameters.  The
practice is somewhat uneven.  An early example is the segregation of
data between /etc/passwd and /etc/shadow; in addition, Secure RPC, 
ssh/sshd, IKE, and 802.11 WEP/WPA all store keys separately from other 
configuration.  
This pattern is found both in code native to Solaris and code
implemented elsewhere.
The Kerberos KDC uses a slightly different approach: it stores wrapped
keys its database, encrypted using a separately-stored master key.
.LP
Several other systems (including MacOS's "Apple Keychain" and GNOME's
"Keyring") implement subsystems specifically for storage of sensitive
properties distinct from the storage of configuration parameters.
.NH 2
Risks of commingling sensitive data
.LP
If critical security parameters are mingled in the clear with other
configuration data, additional security review is appropriate.  In
particular, the combination increases the number of factors affecting
the risks of accidental exposure, exposure through backup media, and
exposure through various end-runs around software layers involved in
protecting the parameters.
.NH 3
Database implementation
.LP 
Details of the database implementation matter, particularly as relates
to whether the original value of a property may be recoverable from
the backing file after a property update or deletion.
.NH 3
Backup
.LP
Critical security parameters stored in a shared file are more likely
to be exposed in backups; it will also additionally be more difficult
to exclude just these parameters from backup.
.NH 2
Use of this facility
.LP
Use of this facilty to store secrets in the clear without additional
practices does not implement all of the recommendations of the
existing Best Practice for password storage[2].  While this may be no
worse than existing behavior in some cases, it is possible to do
better; accordingly, applications using this facility should carefully
review the Best Practice and apply relevant additional protections.
.LP
In addition, since SMF access control is applied at the property group
level, applications must segregate non-public properties into separate
read-protected property groups.  To avoid the need to grant
authorizations too widely, properties which do not need read
protection should not be placed in read-protected property groups.
.LP
Applications creating read-protected property groups do so by
including a "read_authorization" property value.  The authorization
name must correspond to the SMF Policy requirements for such values
and the authorization must be included in an appropriate Rights
Profile.  During initial install of a package, this authorization
value should be set through the import of a service manifest.  
.LP
Consistent with the Secure by Default Policy[7] and the Install-Time
Security Policy[8], service manifests delivered as part of the
installation of a software package must not permit operation using
placeholder sensitive values; services dependent on these values must
behave in a safe manner (typically by denying access) until the
sensitive value is appropriately initialized for real.
.LP
In the event that read-protected property groups are created by other
means (for instance, to store per-service-instance data for a
dynamically changing set of service instances), the read_authorization
property must be set before any sensitive data is stored to ensure
there is no window of time where the sensitive values are unprotected.
.LP
The current implementation of "svccfg import" atomically adds all
properties -- either all or none of the imported values are visible.
The atomicity of this behavior was not previously documented.
However, it has relevance for security (allowing *_authorization
properties to be populated concurrently with the data they protect)
and should be a documented and Committed behavior.
.LP
.NH 2
Related Projects
.LP
The Solaris Cryptographic Framework is based around PKCS#11, which
permits (but does not require) keys to be flagged as "sensitive"; when
used in conjunction with a hardware keystore, this permits entities to
be allowed to use a key without being able to access its value.
.LP
Products implementing a secure keystore include the SCA 4000 ("Venus"[4])
and SCA6000 ("Mars"[5]); in addition, TPM hardware present on many x86
systems appears to have a similar capability, though software support
on Solaris is not yet available.
.LP
Virtualization technologies also have the potential to allow similar
functionality to be implemented, keeping the actual value of critical
keys out of reach of a hosted OS instance.
.LP
It may be appropriate for projects needing read-protected properties
to either encrypt those properties using the encryption framework or
store them using a PKCS#11 token instead; as hardware keystores become
more generally available this should lead to significantly improved
protection against disclosure.
.LP
There is also a pending proposal to add the BSD "NODUMP" attribute
(among others) to request that a file be excluded from backup.[6]
.NH
Minority Opinion(s)
.LP
TBD/None
.NH
Advisory Information
.LP
.RS
.IP 1.
As discussed above in section 4.2, the Security SWG should review the
current password-storage Best Practices document to see if it can be
better phrased to apply to system components such as SMF and to
sensitive parameters other than passwords.
.IP 2.
The Solaris PAC should give priority to a project which implements a
protected system keyring interface for storage of sensitive properties
which can take advantage of underlying hardware keystore facilities if
present.
.RE
.NH
Appendices
.NH 2
Appendix A: Technical Changes Required
.LP
.RS
.IP 1.
The project is renamed to "Read-protected property storage in SMF";
documentation must not imply that the feature provides complete
protection for sensitive values.
.IP 2.
The recommendations in section 4.5 above must be included in
the smf_security(5) man page.
.RE
.NH 2
Appendix B: Technical Changes Advised
.LP
None.
.NH 2
Appendix C: Reference Material
.LP
Unless stated otherwise, path names are relative to the case
directory \*(aR/\*(cA.
.IP 1. 
Project specification.
commit.materials/*
.IP 2.
"Storing Reusable Passwords on a Filesystem" Best Practice
http://www.opensolaris.org/os/community/arc/bestpractices/passwords-files/
.IP 3.
"Security Requirements for Cryptographic Modules", FIPS 140-2.
http://csrc.nist.gov/cryptval/140-2.htm
.IP 4.
"Venus 2.0"
SNARC 2004/077
.IP 5.
"Mars 1.0 Project"
PSARC 2005/617
.IP 6.
Extensible Attribute Interfaces
PSARC 2007/315
.IP 7.
"Secure by Default" Policy
http://www.opensolaris.org/os/community/arc/policies/secure-by-default/
.IP 8.
"Install-Time Security" Policy
http://www.opensolaris.org/os/community/arc/policies/ITS/