Open Stack

Fair enough. I would suggest you re-order your presentation. The proposal
is to enhance control over the rights/privileges/permissions/capabilities
(as defined) associated with a Keystone token. Changing the scope of a
token is a specific instance. This could include disabling/enabling bits,
or disallowing bits (remove the ability to enable a disabled bit).

There are a few use-cases for capabilities to be disabled by default, but
that can be enabled (in Windows and no doubt others). Whether cases of this
sort carry over to the cloud is a question.

You want to be explicit that you are *not* changing existing behavior. (Or
you are, and can justify breaking an unknown number of applications.)

You want this to be an extension (like "OS-trust"), or standard function?
Compared to OS-trust you are allowing fine-grained dynamic control, rather
than static/declarative control. (At least that is my interpretation.)


I used "trust" in human terms. Always fun when different groups use
overlapping definitions for different terms. (Trust, right, privilege,
capability - in security. Instance, virtual machine, server, host - in ...
well, you know.) Certainly you do want to carefully define your use of
terms in security.





On Wed, Dec 17, 2014 at 10:42 AM, Nathan Kinder <nkinder at redhat.com> wrote:
>
>
>
> On 12/17/2014 10:16 AM, Preston L. Bannister wrote:
> > I take issue with choice of words, in your note. The key here is around
> > this statement:
> >
> >     Essentially, this means that any token for a particular user can
> >     indirectly be used to perform any action that user is allowed to
> >     perform.
> >
> >
> > As we are talking about actions the "user is allowed to perform", then
> > we are *not* talking about "privilege escalation". The current behavior
> > is *not* a malfunction that needs fixing.
>
> You are correct that the current behavior is not a bug.  It is a
> behavior that can be misleading though, as one might assume that an
> intercepted token can only be used to perform actions that are allowed
> by that specific token.  This notes is pointing out that the assumption
> that token scope has a security property is incorrect.
>
> >
> > Leaving aside the slightly alarming use of words, what you seem to be
> > proposing is a *new* behavior in Keystone. It sounds like you are
> > proposing a means of creating a scoped token that *cannot* be used to
> > request another token with a different scope.
>
> Yes, this is correct (though these potential enhancements are not the
> intent of the security note).
>
> >
> > The use case that comes to mind is limited trust. You want to pass a
> > token to another service, but you want to limit that service to *less*
> > than the full range of permissions for the user.
> >
> > If the use case is limited trust, then changing the project scope is
> > only one aspect. You might also want to subtract other permissions held
> > by the user.
>
> Yes, absolutely (though it's best to avoid the word 'trust' since that
> has a very specific meaning in Keystone).
>
> Ultimately, being able to request what roles you want a token to contain
> would be ideal.  I describe some of this in my blog post that is
> referenced in the security note.
>
> For this to be useful, the end-user requesting a token needs to have
> some idea of what roles are required to perform a particular action.
> This requires policy related enhancements, which have had some
> discussion on the development mailing list as well as in the design
> sessions at the Summit in Paris.
>
> >
> > The more general case here is the ability to enumerate and enable (if
> > allowed) or disable capabilities. (Windows has some rather elaborate
> > APIs around this, that I have not visited in several years.)
>
> Yes, these are the policy related enhancements I was mentioning.  Being
> able to have API calls to answer the following questions would be useful
> for this:
>
> - What roles to I need to perform action 'x'?
> - What actions can I perform using token 'x'?
>
> This is similar to things like the 'get effective rights' control in LDAP.
>
> >
> > Sounds like you want to *enhance* security via introducing control over
> > capabilities.
>
> That is correct, but the intent of this security note is to raise
> awareness of how Keystone token scope works since it can be easily
> misunderstood form a security perspective.
>
> >
> >
> > I have not spent a lot of time with Keystone, some perhaps I missed
> > something. I do not see anything along that line mentioned. Is there
> > interest in introducing control over capabilities in Keystone tokens?
>
> Absolutely.  Both of the topics mentioned above have been discussed by
> the Keystone development team.  There are various pieces that need to
> fall into place first, but there are efforts underway to improve things
> in this area.
>
> Thanks,
> -NGK
>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Wed, Dec 17, 2014 at 8:18 AM, Nathan Kinder <nkinder at redhat.com
> > <mailto:nkinder at redhat.com>> wrote:
> >
> > Keystone token scoping provides no security benefit
> > ---
> >
> > ### Summary ###
> > Keystone provides "scoped" tokens that are constrained to use by a
> > single project. A user may expect that their scoped token can only be
> > used to perform operations for the project it is scoped to, which is not
> > the case. A service or other party who obtains the scoped token can use
> > it to obtain a token for a different authorized scope, which may be
> > considered a privilege escalation.
> >
> > ### Affected Services / Software ###
> > Keystone, Diablo, Essex, Folsom, Grizzly, Havana, Icehouse, Juno, Kilo
> >
> > ### Discussion ###
> > This is not a bug in keystone, it's a design feature that some users may
> > expect to bring security enhancement when it does not. The OSSG is
> > issuing this security note to highlight the issue.
> >
> > Many operations in OpenStack will take a token from the user and pass it
> > to another service to perform some portion of the intended operation.
> > This token is very powerful and can be used to perform many actions for
> > the user. Scoped tokens appear to limit their use to the project and
> > roles they were granted for but can also be used to request tokens with
> > other scopes. It's important to note that this only works with currently
> > valid tokens. Once a token expires it cannot be used to gain a new
> > token.
> >
> > Token scoping helps avoid accidental leakage of tokens because using
> > tokens with other services requires the extra step of requesting a new
> > re-scoped token from keystone. Scoping can help with audit trails and
> > promote good code practices. There's currently no way to create a
> > tightly scoped token that cannot be used to request a re-scoped token. A
> > scoped token cannot be relied upon to restrict actions to only that
> > scope.
> >
> > ### Recommended Action ###
> > Users and deployers of OpenStack must not rely on the scope of tokens
> > to limit what actions can be performed using them.
> >
> > Concerned users are encouraged to read (OSSG member) Nathan Kinder's
> > blog post on this issue and some of the potential future solutions.
> >
> > ### Contacts / References ###
> > Nathan Kinder on Token Scoping : https://blog-nkinder.rhcloud.com/?p=101
> > This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0042
> > Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1341816
> > OpenStack Security ML : openstack-security at lists.openstack.org
> > <mailto:openstack-security at lists.openstack.org>
> > OpenStack Security Group : https://launchpad.net/~openstack-ossg
> >
> >     _______________________________________________
> >     Mailing list:
> >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> >     Post to     : openstack at lists.openstack.org
> >     <mailto:openstack at lists.openstack.org>
> >     Unsubscribe :
> >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20141217/19b65d07/attachment.html>