[Openstack-security] Credentials in clear text
Adam Young
ayoung at redhat.com
Wed Apr 23 12:33:09 UTC 2014
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>
>>
>> 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>
>>
>> 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>
>>
>> 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/979b6789/attachment.html>
More information about the Openstack-security
mailing list