Open Stack

To those not familiar with David, understand that he is a security 
researcher whom I hold in fairly high regard.  We've discussed numerous 
aspects of Keystone at great length.  He'll be familiar with my 
responses, but others will be less so.

On 03/15/2013 01:16 PM, David Chadwick wrote:
> 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 simpo hly use the term delegation, 
> since this is the well known concept and it should be sufficient to 
> cover all the use cases you require.

Yes...but...the term delegation has been used for many things, in the 
area of Keystone and elsewhere.  We were using it for two different  
blueprints when we first started discussing what is now called trusts.  
The concept of delegation of authority here is specifically that of a 
user to user delegation.  The term trust was selected to handle 
specifically the agreement for later setting up a delegation, and it was 
this distinction that lead to using the word "Trust."  The analogy is to 
Legal trusts, used to hand off management of assets.  The language of 
trusts, trustor, and trustee makes things very clear to a degree that I 
have not always found in Identity Management.



>
> 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).
Not allowing impoersonation is probably the right thing the abstract, 
but due to the way Swift in particular manages ownership, which is at 
the per user level, the attribute that needs to be delegated is, 
unfortunately, the user_id of the owner of the object.  Systems are 
currently built around users surrendering control of their password just 
as you state above.  Impersonation is a step in the right direction.  I 
would be happy to remove the impersonation aspect of trusts once it is 
no longer needed.

As far as audting, however, this is the possibiility of an audit trail.  
The token used to perform the action records the trustee ID regardless 
of whether impersonation is in effect or not.  Even if all the remote 
service logs is the token ID used to perform and action, there is still 
enough information in Keystone to link that back to 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?
Currently, only roles can be delegated (well, and the user_Id in the 
case of impersonation).  If we allow delegation of additional attributes 
in the future, we can certainly provide constraints on what can and 
cannot be delegated.

>
> 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".
Such has been my goal.  Keystone as it exists now did not undergo such a 
rigorous process in the past, and so we have a system that needs 
improvement.  I think that the use of bearer tokens is the number one 
thing we want to address in the next release, and I would argue that we 
cannot properly deal with them without a delegation mechanisms such as 
Keystone trusts.  I think that David agrees with me on this, and is not 
attacking the base concept, just that he disagrees with the 
implementation details.


>
> 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-identity-api/src/markdown/identity-api-v3.md#trusts 
>>
>>
>> [3]:
>> https://github.com/openstack/identity-api/blob/master/openstack-identity-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