Open Stack

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>