[Openstack-security] Credentials in clear text
Adam Young
ayoung at redhat.com
Thu Apr 24 01:54:26 UTC 2014
On 04/23/2014 10:24 AM, Tim Bell wrote:
>
> I think Jose from CERN has been putting in some work on the clients
> and the server for Kerberos in this area.
>
Yes, I've been working with him on this. Jamie Lennox is working on the
necessary Client mechanisms to make various auth plugins available from
the Unified CLI, etc.
>
> 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.
>
Kerberos Requests needs an upstream release we can pull in. There is a
change in master not in a released package that we need for Python33
> 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.
>
There is a client talk, but not about this specifically. We can work
out details in the Developers lounge, though, and also in the General
client talks.
> Tim
>
> *Activity Log*
>
> 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*
>
> 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*
>
> 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>
>
> 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
> <mailto: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
> <mailto: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]
> *Sent:* 22 April 2014 01:16
> *To:* Adam Lawson
> *Cc:* openstack-security at lists.openstack.org
> <mailto: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 <mailto: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
> <tel:%2B1%20%28302%29%20268-6914>
>
> 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 <mailto: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
> <tel:%2B1%20%28302%29%20268-6914>
>
> 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
> <mailto: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
> <mailto: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
> <tel:%2B1%20%28302%29%20268-6914>
>
> Image removed by sender.
> http://www.aqorn.com/images/logo.png
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> <mailto: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 <mailto: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
> <mailto: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/716b73bb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 4333 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/716b73bb/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1686 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/716b73bb/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 410 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/716b73bb/attachment.jpe>
More information about the Openstack-security
mailing list
