Open Stack

On 15/03/2013 20:55, Gabriel Hurley wrote:
> I agree with dome of David's points (particularly point two about the
> inscrutability of the actor during impersonation), but more
> importantly I would like to ask that this discussion stay friendly
> and constructive.

thankyou for this

>
> This feature was discussed at tremendous length here on this mailing
> list and the specification underwent numerous public revisions.

the problem is that the there is no formal governance structure as such, 
say as in the IETF or OASIS, as the blueprint writer can decide what to 
accept and what not to accept and then go ahead and code it up. Whilst 
Adam did make some changes that I suggested, and acknowledged this in 
the spec, I still dont think the review process is rigorous enough for 
security related features. It might be OK for non-security specs, but I 
think that security features should have a more rigorous design phase 
with a formal sign off or similar as used by the IETF, OGF and OASIS. 
Ultimately we want OpenStack to be secure enough for commercial 
companies to use without worrying about the backdoors and flaws in the 
design. I dont know if you agree with what I am saying or not. If you do 
agree, I dont know the best way to go about trying to change the current 
procedure, do you?

If you think I am way off beam, please say


  Short
> of explicitly requiring that the OpenStack Security Group sign off on
> features/specifications I'm not sure more could/should have been
> done.

this is what I proposed as a way of tightening up the security features

  There's no reason these issues couldn't have been raised during
> the design phase, so being pejorative about it now is unnecessary.

I did, but because of the way the current scheme operates, any proposals 
can be ignored with no justification given.


regards

David
>
> Dolph was simply trying to make a final effort to raise awareness for
> those who hadn't noticed or had chosen not to pay attention to the
> earlier phases, and I'm glad he did since there are likely still
> issues that should be revisited in the H cycle.
>
> All the best,
>
> - Gabriel
>
>> -----Original Message----- From: David Chadwick
>> [mailto:d.w.chadwick at kent.ac.uk] Sent: Friday, March 15, 2013 10:16
>> AM To: OpenStack Development Mailing List Subject: Re:
>> [openstack-dev] [OSSG] [keystone] Trusts: delegation and
>> impersonation
>>
>> Here are my comments, some of which I have made before in various
>> previous emails
>>
>> 1. Trusts is actually the concept of delegation, and you should
>> remove the term trusts altogether and simply use the term
>> delegation, since this is the well known concept and it should be
>> sufficient to cover all the use cases you require.
>>
>> 2. From a security perspective, impersonation (where the service
>> cannot tell the difference between the real user and the imposter)
>> should be a no-go area. You simply should not provide any support
>> for it, as the system looses all means of auditing who did what,
>> and the delegator has no means of controlling what the delegate is
>> entitled to do. (Clearly you cannot forbid it, since anyone can
>> give their authentication credentials to anyone else, but from the
>> service's perspective, this is always the user who is accessing
>> the resource and must take full responsibility for this, and it is
>> not the impersonator). It maybe that the functionality your require
>> is to delegate a user's full set of privileges, but this should
>> still be done by delegation and not by impersonation, as then the
>> system retains a full audit of who did what. However in the
>> specification you set the user attribute of the delegation to that
>> of the trustor instead of the trustee. This is bad, as the
>> generated token is then in the name of the trustor rather than the
>> trustee. In my opinion the impersonation feature should be removed
>> as quickly as possible.
>>
>> 3. A user should be able to delegate any of his authz privileges,
>> depending upon the constraints of the privilege authority. So, for
>> example, I can delegate my role if the role/attribute authority
>> allows it. Otherwise I cannot. I dont believe you have this
>> constraint in your model, so it is a deficiency. For example,
>> whilst I might be able to delegate my role A to someone else, I
>> should not be able to delegate my age or my current location (both
>> of which can be authz attributes e.g. for age related and location
>> related services). So the attribute authority must be able to
>> control whether delegation is allowed or not, and if it is, how
>> much it is (e.g. length of delegation chains). You typically can
>> never delegate your driving license to anyone. So who is the
>> attribute authority for the attributes that are currently being
>> delegated in your "trusts" model, and how do they control this?
>>
>> 4. Before you do any coding of security functionality ideally you
>> should have a properly specified design that has been rigorously
>> reviewed and agreed upon (and the security group of OpenStack
>> should sign these off before implementation proceeds). Security is
>> very hard to get right, and simply going ahead and coding something
>> up first without a proper design and review phase, is in my opinion
>> folly. (I think Keystone suffers from a number of such
>> functionalities.) You will end up wasting time in the long run, due
>> to the amount of bug fixing and re-factoring you will have to do,
>> and you will also introduce security vulnerabilities into your
>> system as well, due to an improperly specified or insufficiently
>> reviewed design. We all know that the current Keystone system has a
>> number of such "features".
>>
>> In summary, I would like to improve the security of Keystone, but I
>> think that an improved way of working is needed
>>
>> regards
>>
>> David
>>
>> On 14/03/2013 18:59, Dolph Mathews wrote:
>>> This is a feature that just landed in Grizzly which could
>>> certainly use some extra security-focused eyes.
>>>
>>> There's two use cases being addressed:
>>>
>>> 1) Scoped role delegation with optional impersonation: "I trust
>>> user X to perform role Y on project Z, optionally for some
>>> duration of time, and optionally while impersonating me."
>>>
>>> 2) Impersonation: "I trust user X to impersonate me, optionally
>>> for some duration of time."
>>>
>>> In short, a trust is created by a trustor; the trustee must
>>> first authenticate as themselves, and then may consume the trust
>>> by specifying it's ID (which is not necessarily a secret); the
>>> trustee then receives a token with the project and associated
>>> roles as specified by the trustor; the generated token may also
>>> reflect the trustor's identity, instead of the trustees (but will
>>> contain an impersonation flag to indicate this behavior).
>>>
>>> The original blueprint [1] outlines the goal of the feature and
>>> contains links to relevant patches. The Identity API v3
>>> specification contains a fairly thorough overview of the final
>>> concept [2] along with a examples for each of the related API
>>> calls [3]. The implementation is mostly housed in the
>>> keystone.trust package [4] although it also affects both v3 and
>>> v2 auth flows, in the keystone.auth [5] and keystone.token [6]
>>> packages, respectively.
>>>
>>> [1]: https://blueprints.launchpad.net/keystone/+spec/trusts
>>>
>>> [2]:
>>> https://github.com/openstack/identity-api/blob/master/openstack-identi
>>>
>>>
ty-api/src/markdown/identity-api-v3.md#trusts
>>>
>>> [3]:
>>> https://github.com/openstack/identity-api/blob/master/openstack-identi
>>>
>>>
ty-api/src/markdown/identity-api-v3.md#trusts-1
>>>
>>> [4]:
>>> https://github.com/openstack/keystone/tree/master/keystone/trust
>>>
>>> [5]:
>>> https://github.com/openstack/keystone/tree/master/keystone/auth
>>>
>>> [6]:
>>> https://github.com/openstack/keystone/tree/master/keystone/token
>>>
>>> Thanks for all your hard work, Adam!
>>>
>>> -Dolph
>>>
>>>
>>> _______________________________________________ OpenStack-dev
>>> mailing list 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
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________ OpenStack-dev mailing
> list OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>