Open Stack

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.




*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 7:24 AM, Tim Bell <Tim.Bell at cern.ch> wrote:

>
>
> I think Jose from CERN has been putting in some work on the clients and
> the server for Kerberos in this area.
>
>
>
> There were some problems with the Kerberos packaging and pre-reqs along
> with how to fake a Kerberos server in the test suite but he was making
> progress.
>
>
>
> Is this on the summit agenda ? It would be good to get it working since I
> think it was on my summit talk in Boston.
>
>
>
> Tim
>
>
>
> *Activity Log*
>
> [image: http://www.gravatar.com/avatar/a1040384?s=64&d=identicon]
>
> *Jose Castro Leon
> <http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&release=all&metric=all&company=> (CERN
> <http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=CERN>)*
>
> *08 Apr 2014 07:14:32 in python-keystoneclient
> <http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=&module=python-keystoneclient>*
>
> *Review "Initial kerberos plugin implementation."*
>
> Submitted by: Jose Castro Leon<http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&release=all&metric=all&company=>
>  (CERN<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=CERN>)
> (#35)
>
> Change Id: Idf02bf27b5933c00827dd08d11ac131896184ad8<https://review.openstack.org/74974>
>
> Code Review: *1*
>
> [image: http://www.gravatar.com/avatar/a1040384?s=64&d=identicon]
>
> *Jose Castro Leon
> <http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&release=all&metric=all&company=> (CERN
> <http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=CERN>)*
>
> *02 Apr 2014 14:59:32 in requirements
> <http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=&module=requirements>*
>
> *Review "kerberos requires an additional requests library. Older versions
> break in py33"*
>
> Submitted by: Adam Young<http://stackalytics.com/?user_id=ayoung&project_type=all&release=all&metric=all&company=>
>  (Red Hat<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=Red+Hat>)
> (#200)
>
> Change Id: I2100915f123c0fea41d5b17d01947901aa0119c5<https://review.openstack.org/84740>
>
> Code Review: *1*
>
> [image: http://www.gravatar.com/avatar/a1657571576?s=64&d=identicon]
>
> *Jose Castro Leon
> <http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&release=all&metric=all&company=> (CERN
> <http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=CERN>)*
>
> *20 Feb 2014 09:21:31 in python-keystoneclient
> <http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=&module=python-keystoneclient>*
>
> *Patch "Initial kerberos plugin implementation."*
>
> Current Status: ABANDONED
>
> Change Id: Idf02bf27b5933c00827dd08d11ac131896184ad8<https://review.openstack.org/74974>
>
> [image: http://www.gravatar.com/avatar/a1657571576?s=64&d=identicon]
>
> *Jose Castro Leon
> <http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&release=all&metric=all&company=> (CERN
> <http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=CERN>)*
>
> *18 Feb 2014 10:19:23 in keystone
> <http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=&module=keystone>*
>
> *Patch "Initial kerberos plugin implementation."*
>
> Current Status: ABANDONED
>
> Change Id: I2fad67c3613c273187f6ca32985d360352c81bf8<https://review.openstack.org/74317>
>
>
>
>
>
>
>
> *From:* Nathanael Burton [mailto:nathanael.i.burton.work at gmail.com]
> *Sent:* 23 April 2014 14:42
> *To:* Adam Young
>
> *Cc:* openstack-security at lists.openstack.org
> *Subject:* Re: [Openstack-security] Credentials in clear text
>
>
>
> We have to configure the Apache layer to set the component we want as the
> REMOTE_USER, but other than that I believe that's pretty much all it takes
> on the Keystone side. Changes were necessary to some of the Python clients
> and service code, mainly to get them to pass certificates along.  Not all
> these changes have been proposed upstream yet, although we plan to.
>
> Thanks,
>
> Nate
>
> On Apr 23, 2014 8:33 AM, "Adam Young" <ayoung at redhat.com> wrote:
>
>  On 04/23/2014 08:29 AM, Nathanael Burton wrote:
>
> We do this today with X509 certificates using the external auth plugin for
> Keystone. Services and users auth directly with X509 certificates to get
> tokens.
>
>
> Have you modified it at all?  I have yet to try, but I though with mod_ssl
> and external, REMOTE_USER was not set.  It was my understanding that the
> following vars were set in its place:
>
> http://www.freeipa.org/page/Environment_Variables#X.509_Authentication
>
>
>  Nate
>
> On Apr 23, 2014 12:23 AM, "Adam Young" <ayoung at redhat.com> wrote:
>
>  On 04/22/2014 11:29 AM, Clark, Robert Graham wrote:
>
>  As Bryan mentioned already, a user with access to production systems,
> particularly one with sudo/root access - is in an incredibly privileged
> position. On its own this is an auditing issue but it's a recognised one.
> In most deployments subject to auditing (i.e. production) it's likely that
> compensating controls such as gated access, user logging, MAC etc. are all
> in place to control the risk.
>
> It's a messy problem to deal with. I've seen approaches where the process
> and configuration file are both owned by an elevated user, once the process
> has loaded the configuration file it drops privs and can no longer read the
> file, this can be useful as a mechanism for avoiding directory traversal in
> web services etc I'm not sure how viable an approach this would be with
> something like Swift.
>
>
>
> -Rob
>
>
> I'd like to see a concerted effort to allowing all servcie to get keystone
> tokens with either Kerberos (keytabs) or X509 Client certificates.
>
>
>
>
> *From:* Bryan D. Payne [mailto:bdpayne at acm.org <bdpayne at acm.org>]
> *Sent:* 22 April 2014 01:16
> *To:* Adam Lawson
> *Cc:* openstack-security at lists.openstack.org
> *Subject:* Re: [Openstack-security] Credentials in clear text
>
>
>
> This is fair.  I'm not personally familiar with Swift, so I will let
> others chime in on that.
>
> -bryan
>
>
>
> On Mon, Apr 21, 2014 at 4:47 PM, Adam Lawson <alawson at aqorn.com> wrote:
>
>  Preventing access to passwords for the purpose of preventing
> unauthorized access to data as another way I look at it.
>
>
>
> * 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
>
> [image: Image removed by sender. http://www.aqorn.com/images/logo.png]
>
>
>
> On Mon, Apr 21, 2014 at 4:46 PM, Adam Lawson <alawson at aqorn.com> wrote:
>
>  My initial concern is specific to Swift and gaining global access to all
> data by virtue of having access to a single proxy node. It seems more than
> access to system resources but a flaw in how data is controlled (and
> passwords are controlled).
>
>
>
> * 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
>
> [image: Image removed by sender. http://www.aqorn.com/images/logo.png]
>
>
>
> On Mon, Apr 21, 2014 at 4:41 PM, Bryan D. Payne <bdpayne at acm.org> wrote:
>
>  This would be a nice hardening step, but if you have sudo on the box
> there's a lot of things you can do see.  This is just the tip of the
> iceberg.  For example, access to the backend db?  Access to traffic on the
> network / unix sockets / etc?  Access to logs.
>
>
>
> I am not aware of any current efforts to mask this information from the
> config files.  But that doesn't mean it's not happening.  If someone is
> aware of such an effort, I'd certainly be interested in learning more about
> it.
>
>
>
> Cheers,
>
> -bryan
>
>
>
>
>
>
>
> On Mon, Apr 21, 2014 at 4:26 PM, Adam Lawson <alawson at aqorn.com> wrote:
>
>   Have .conf files containing credentials and tokens been addressed or
> being addressed? Seems there are a lot of keys to the kingdom clearly
> visible to staff who have access to systems for day-to-day admin work but
> don't/shouldn't be able to view them. If they have sudo access, they have
> everything they need to get where they don't belong. Really strikes me as
> an obvious audit issue...
>
>
>
> * 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
>
> [image: Image removed by sender. http://www.aqorn.com/images/logo.png]
>
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> Openstack-security mailing list
>
> Openstack-security at lists.openstack.org
>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/f96467bd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 410 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/f96467bd/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 1686 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/f96467bd/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4333 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/f96467bd/attachment-0001.png>