Open Stack

Totally fair Bryan - just trying to sort through this because it came up as
an audit finding. Re that last question, that's the rub for me. For a
service to start, decryption requires a key. Armed with the key, a
nefarious sysadmin can open the file and get the rest of the data. But I'm
struggling with the all or nothing dynamic. I know in Windows, a local
user/password can be set to start a service and that password cannot be
identified by looking at some text file. Unix works a little differently I
know. Okay, a lot differently. ; )

Ideas I had (feel free to blow these up):

   - encrypting the conf file
   - encrypting just the tokens/passwords values within the conf file
   - starting services from a remote location which reduces the credential
   exposure to sysadmins

Also open to other ideas. Is the problem statement clear though / what I'm
trying to sort through? Is embedding credentials in text files best
practice or is it such a common practice that the method isn't really that
big of a deal? Would prefer not to boil the ocean if I can avoid it but
trying to find a path forward...



*Adam Lawson*
AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW
Direct: +1 (302) 268-6914



On Wed, Apr 23, 2014 at 1:30 PM, Bryan D. Payne <bdpayne at acm.org> wrote:

> There are several issues with this approach and the code below.  But
> perhaps the clearest way to understand the issue here is to ask, "Where
> would the decryption password be stored?"
>
> -bryan
>
>
> On Wed, Apr 23, 2014 at 9:48 AM, Adam Lawson <alawson at aqorn.com> wrote:
>
>> How feasible (or unfeasible) would it be for each service to look for an
>> encrypted conf file and use the clear text version if the encrypted file
>> doesn't exist? The file could be all settings but technically only
>> credentials and tokens would need this level of protection in my estimation.
>>
>> I could envision doing this, for example, with OpenSSL as follows (bash
>> for example):
>>  #!/bin/bash
>>  #OpenSSL file encryption
>> decrypt=credentials.txt
>> encrypt=${decrypt}.encrypted
>> if [[ $# -eq 0 ]] ; then #encrypt creds in file
>>     read username
>>     read -s password
>>     #write creds to the file
>> echo ${username}:${password} | openssl des3 -salt  -out $encrypt
>> elif [[ $1 = '-d' ]] ; then #decrypt creds from file
>>     openssl des3 -d -salt -in $encrypt -out $decrypt
>> else
>>     echo "Error: $1 invalid. Decrypt='-d', Encrypt=no-args" >&2
>>     exit 1
>> fi
>>
>> Thoughts? It just seems (to me of course) like a meaningful design option
>> for companies who cannot afford to give credentials to all sysadmins with
>> sudo access to *any* of the nodes for a given solution.
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/df9ee57b/attachment.html>