On Wed, Mar 28, 2007 at 11:29:32AM -0400, Bill Sommerfeld wrote: > 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.
There are two general possibilities. A keyless reversible scheme (such as used in the ldap_client_cred case I noted previously) would provide no additional protection, only obscurity. A keyed scheme, as Darren pointed out, would still need to obtain a master key of some kind from somewhere. In the long run, hardware may help, but that hardware does not exist or cannot be used effectively today. So it would have to be either the repository or another locally-stored file owned by root and readable to no one else. This seems to provide additional complexity with no additional benefit, given that the repository itself already has those attributes. > 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. There are two preexisting problems here: storage of sensitive data, and reversible obfuscation or encryption of it. Today's world leaves each service responsible for all aspects of both. This case attempts to solve the first of these by providing a repository-based protection mechanism superior to the use of discrete files. It does not attempt to resolve the other orthogonal problem: providing a generic mechanism for obfuscation or encryption of sensitive data prior to its storage. I believe this second problem should be addressed separately. -- Keith M Wesolowski "Sir, we're surrounded!" FishWorks "Excellent; we can attack in any direction!"
