sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: SMF Read-protected Property Storage Submitted by: Keith Wesoloski File: PSARC/2007/177/opinion.ms Date: TBD Committee: TBD Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary 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. 2. Decision & Precedence Information The project is approved as specified in reference [1], but as modified by the required technical changes listed in Appendix A below. The project may be delivered in a patch release of the ON consolidation. The project depends on the following other project and may not be delivered before it: 6546699 svccfg archive should be able to be reimported 3. Interfaces The project exports the following interfaces. _________________________________________________________ | Interfaces Exported | |____________________|________________|_________________| |Interface | Classification| Comments | |____________________|________________|_________________| | | | | | | | | | | | | |____________________|________________|_________________| PSARC/2007/177 Copyright 2007 Sun Microsystems - 2 - _________________________________________________________ | Interfaces Exported | |____________________|________________|_________________| |Interface | Classification| Comments | |____________________|________________|_________________| |read_authorization | Committed | SMF Property;| | | | new with this| | | | project | |modify_authorization| Committed | SMF Property;| | | | revision of| | | | prior Evolving | |value_authorization | Committed | SMF Property;| | | | revision of| | | | prior Evolving | |svccfg export -a | Committed | Includes read-| | | | protected pro-| | | | perties. | |svccfg archive -a | Committed | Includes read-| | | | protected pro-| | | | perties. | |svccfg import | Committed | All imported| | | | property | | | | changes become| | | | visible simul-| | | | taneously. | | | | (See below) | |____________________|________________|_________________| 4. Opinion 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 archi- tectural 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. 4.1. Background First, it's worth noting that when examining system secu- rity, it is necessary to look at 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. PSARC/2007/177 Copyright 2007 Sun Microsystems - 3 - 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 misconfi- guration may expose the value. 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 pass- words 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. 4.2. Applicable Best Practices Many of the recommendations found in existing "Storing Reus- able 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: "... it is recommended that the actual reusable pass- word should be stored on the filesystem in either an encrypted or obfuscated format in order to help prevent against accidental disclosure." "... 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." Unfortunately the text is focussed around interactive appli- cation considerations; many of the recommendations contain aspects that are not directly applicable to system com- ponents like SMF; some revision to the document seems to be called for to clearly show applicability of these concepts to system components. 4.3. Existing Practice Many existing subsystems within solaris store critical secu- rity parameters separately from other configuration parame- ters. 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 PSARC/2007/177 Copyright 2007 Sun Microsystems - 4 - 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. 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. 4.4. Risks of commingling sensitive data 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 expo- sure, exposure through backup media, and exposure through various end-runs around software layers involved in protect- ing the parameters. 4.4.1. Database implementation 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. 4.4.2. Backup Critical security parameters stored in a shared file are more likely to be exposed in backups; it will also addition- ally be more difficult to exclude just these parameters from backup. 4.5. Use of this facility Use of this facilty to store secrets in the clear without additional practices does not implement all of the recommen- dations 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; accord- ingly, applications using this facility should carefully review the Best Practice and apply relevant additional pro- tections. In addition, since SMF access control is applied at the pro- perty group level, applications must segregate non-public properties into separate read-protected property groups. To avoid the need to grant authorizations too widely, proper- ties which do not need read protection should not be placed in read-protected property groups. Applications creating read-protected property groups do so by including a "read_authorization" property value. The PSARC/2007/177 Copyright 2007 Sun Microsystems - 5 - 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. 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; ser- vices dependent on these values must behave in a safe manner (typically by denying access) until the sensitive value is appropriately initialized for real. 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 sen- sitive data is stored to ensure there is no window of time where the sensitive values are unprotected. 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 secu- rity (allowing *_authorization properties to be populated concurrently with the data they protect) and should be a documented and Committed behavior. 4.6. Related Projects 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 key- store, this permits entities to be allowed to use a key without being able to access its value. 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 simi- lar capability, though software support on solaris is not yet available. 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. 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 avail- able this should lead to significantly improved protection against disclosure. PSARC/2007/177 Copyright 2007 Sun Microsystems - 6 - There is also a pending proposal to add the BSD "NODUMP" attribute (among others) to request that a file be excluded from backup.[6] 5. Minority Opinion(s) TBD/None 6. Advisory Information 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. 2. The Solaris PAC should give priority to a project which implements a protected system keyring inter- face for storage of sensitive properties which can take advantage of underlying hardware keystore facilities if present. 7. Appendices 7.1. Appendix A: Technical Changes Required 1. The project is renamed to "Read-protected property storage in SMF"; documentation must not imply that the feature provides complete protection for sen- sitive values. 2. The recommendations in section 4.5 above must be included in the smf_security(5) man page. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2007/177. 1. Project specification. commit.materials/* 2. "Storing Reusable Passwords on a Filesystem" Best Prac- tice http://www.opensolaris.org/os/community/arc/bestpractices/passwords- files/ 3. "Security Requirements for Cryptographic Modules", FIPS 140-2. http://csrc.nist.gov/cryptval/140-2.htm PSARC/2007/177 Copyright 2007 Sun Microsystems - 7 - 4. "Venus 2.0" SNARC 2004/077 5. "Mars 1.0 Project" PSARC 2005/617 6. Extensible Attribute Interfaces PSARC 2007/315 7. "Secure by Default" Policy http://www.opensolaris.org/os/community/arc/policies/secure- by-default/ 8. "Install-Time Security" Policy http://www.opensolaris.org/os/community/arc/policies/ITS/ PSARC/2007/177 Copyright 2007 Sun Microsystems