Open Stack

On 07/02/2014 01:16 AM, Shohel Ahmed wrote:
> Bringing this to OSSG attention. 
> 
> The second one seems a security critical assumption. Without
> input/output validation in keystone/Swift for domain_id or good
> documentation in place, this assumption can be exploited later on by
> some attacker to break Swift.

Yeah, I'm a bit concerned as well.  Making assumptions about the domain
names that are allowed is bad.  If there is a need for a special string
that can't be used for a valid domain, Keystone should enforce that
restriction.  That said, I haven't looked at the proposed Swift changes
in detail yet to fully understand the approach.

-NGK

> 
> ...shohel
> 
> 
> 
> 
> On Tuesday, July 1, 2014 10:19 PM, Dolph Mathews
> <dolph.mathews at gmail.com> wrote:
> 
> On Tue, Jul 1, 2014 at 11:20 AM, Coles, Alistair <alistair.coles at hp.com
> <mailto:alistair.coles at hp.com>> wrote:
> 
>     We have a change [1] under review in Swift to make access control
>     lists compatible with migration to keystone v3 domains. The change
>     makes two assumptions that I’d like to double-check with keystone
>     folks:____
>     __ __
>     __1.      __That a project can never move from one domain to another.
> 
> We're moving in this direction, at least. In Grizzly and Havana, we made
> no such restriction. In Icehouse, we introduced such a restriction by
> default, but it can be disabled. So far, we haven't gotten any
> complaints about adding the restriction, so maybe we should just add
> additional help text to the option in our config about why you would
> never want to disable the restriction, citing how it would break swift?
> 
>     ____
>     __2.      __That the underscore character cannot appear in a valid
>     domain id – more specifically, that the string ‘_unknown’ cannot be
>     confused with a domain id.
> 
> That's fairly sound. All of our domain ID's are system-assigned as
> UUIDs, except for the "default" domain which has an explicit
> id='default'. We don't do anything to validate the assumption, though.
> 
> 
> 
> 
> 
> 
>     ____
>     __ __
>     Are those safe assumptions?____
>     __ __
>     Thanks,____
>     Alistair____
>     __ __
>     [1] https://review.openstack.org/86430____
> 
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org <mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>