On Thu, 2007-03-22 at 15:04 -0700, Keith M Wesolowski wrote: > 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.
FWIW, the password storage best practice is also published at: http://www.opensolaris.org/os/community/arc/bestpractices/passwords-files/ > 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. I believe that for reasons cited in the Best Practice that SMF should take additional measures to protect property values identified as sensitive and that those measures should receive open review. This is especially true since if this option is successful there may be large numbers of sensitive values stored in that file. > Nevertheless, storing encrypted or, especially, obfuscated passwords > in the repository is advantageous because it allows optional > assignment of fine-grained authorizations. ... > 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. I'm a little confused about exactly who becomes responsible for encrypting the sensitive credential in this case -- is it SMF or is it the individual service? I'm uncomfortable with leaving this to the individual service (since it effectively forces each service to reinvent their own wheel), especially without very specific guidance in the SMF documentation. - Bill
