On Wed, Mar 28, 2007 at 12:04:00PM -0400, Bill Sommerfeld wrote: > Making components other than SMF do the encryption/obfuscation doesn't > actually solve that problem, and, if anything, makes solving the problem > harder.
We're not imposing any new requirements on those components. They already have to (and do, to the extent that they adhere to the policy) encrypt or obfuscate the tokens. This case deals only with where the encrypted/obfuscated tokens are stored, not how they are transformed. A future case could provide a generic mechanism for encrypting and decrypting these properties, and libscf mechanisms for doing so. However, without extreme care that would actually cause a net reduction in security: all services wishing to read the property values would have to be run as root, or with the full set of privileges, in order to read the key file. As it stands, services could be run with reduced privileges and make use of more specific authorizations to obtain the values of its own properties (but not those associated with other services). An intermediate solution might provide for a simple keyless obfuscation mechanism that would not suffer from this deficiency. Either way, however, I assert that this issue is orthogonal to the one being addressed here. > In the absence of a secure token, merely placing the SMF repository key > in a separate file reduces the risk of accidental exposure of sensitive > properties (for instance, through a "grep .. *" as root in the wrong > directory). That's true only to the extent that the components would fail to encrypt or obscure sensitive data stored in the repository, but would do so properly when storing it in files. Such a bug is made no more likely by changing the storage mechanism. -- Keith M Wesolowski "Sir, we're surrounded!" FishWorks "Excellent; we can attack in any direction!"
