[Openstack-security] Credentials in clear text
Adam Young
ayoung at redhat.com
Wed Apr 23 04:21:47 UTC 2014
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
> *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
> 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/c1da6e93/attachment.html>
More information about the Openstack-security
mailing list