On Thu, Mar 22, 2007 at 02:57:15PM -0400, Bill Sommerfeld wrote: > I'm not comfortable with mixing sensitive properties into the main > property database - in the past, my advice to other projects (including > the wifi folks) has always been to isolate sensitive properties into > separate files so that we can in the future improve the protection of > them without complicating access to non-sensitive fields. > > In addition, the recommendation in the "password storage" best practice: > http://sac.eng/cgi-bin/bp.cgi?NAME=passwords-storage.bp > is that passwords and similar sensitive values be encrypted when stored > in the filesystem.
This case does not propose a change to that policy. If the ARC feels that the repository (which as Gary pointed out is readable only by root and stored in a non-shared filesystem, as specified by the policy) does not provide "sufficient protection" as defined by the policy with respect to a particular project, it is free to require that project team to take alternate measures. Nevertheless, storing encrypted or, especially, obfuscated passwords in the repository is advantageous because it allows optional assignment of fine-grained authorizations. It also makes possible adherence to the SMF Policy[0], specifically the requirement that "[p]rojects intending to integrate new system or service configuration files (which traditionally reside within the /etc/* directory hierarchy) into Solaris must use the Service Configuration Facility (SCF), libscf(3LIB), as their repository for system configuration..." by reducing the set of circumstances in which security considerations would preclude a project team from doing so. As an example, PSARC/2000/363 (Native LDAP Phase II) places an obfuscated password in /var/ldap/ldap_client_cred. Converting this service to use the SMF repository demands the capability proposed by this case; to quote from that case's materials[1]: # All credential information stored in this file is encrypted using # a simple two way encryption mechanism. The security of the # credential is not the encryption, but rather the file permission. The functionality proposed here permits such a credential to be stored securely in the SMF repository, by default readable only by root, and at the same time would allow greater administrative flexibility in accessing or modifying this value, reducing the number of potential administrative tasks requiring full privileges. [0] http://www.opensolaris.org/os/community/arc/policies/SMF-policy/ [1] PSARC/2000/363 Native LDAP Phase II, Architecture Specification sec. 8.2. -- Keith M Wesolowski "Sir, we're surrounded!" FishWorks "Excellent; we can attack in any direction!"
