[Openstack] [OSSN 0042] Keystone token scoping provides no security benefit

Morgan Fainberg morgan.fainberg at gmail.com
Wed Dec 17 18:47:03 UTC 2014

> On Dec 17, 2014, at 1:16 PM, Preston L. Bannister <preston at bannister.us> 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, this is not a privilege escalation. However, it can present in a fashion that could surprise someone and look like a privilege escalation. In short, if I have a token for project X and I have a role on Project Y I can use the token to get access (with my normal set of roles for project Y) on Project Y. The Keystone team generally has a positive view of limiting what tokens can re-scope just to make the behavior more explicit and consistent for users; the limited re-scope is definitely classified as an enhancement not as a defect. Nathan’s verbiage (while potentially slightly alarming) is absolutely correct.

> 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.
> 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.

We already have the capability in Keystone to delegate limited sets of roles to another user. This is handled via the Trusts extension (OS-TRUST API): http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-trust-ext.html <http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-trust-ext.html> however, it is a large amount of overhead to setup a trust for every action within OpenStack. There are cases where limiting the re-scoping of a token to another project/domain provides a better security profile since the “re-scoping” token would only ever be used to communicate with Keystone. This limits the damage that could be done to a single project in the case of a mis-behaving service (either intentional or unintentional). This new functionality would not solve the problems that trusts solve.

> 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.
> 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.)
> Sounds like you want to *enhance* security via introducing control over capabilities.
> 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?

We have open discussions on making the delegation of capabilities a better API and we are actively working to improve the other associated mechanisms (such as allowing a project/deployment/etc to require an x509 client cert or krb5) for cases where a higher level of assurance of the identity of the user that is presenting the token.

Morgan Fainberg

> On Wed, Dec 17, 2014 at 8:18 AM, Nathan Kinder <nkinder at redhat.com <mailto:nkinder at redhat.com>> wrote:
> Hash: SHA1
> 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 <https://blog-nkinder.rhcloud.com/?p=101>
> This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0042 <https://wiki.openstack.org/wiki/OSSN/OSSN-0042>
> Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1341816 <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 <https://launchpad.net/~openstack-ossg>
> Version: GnuPG v1
> LUyLIFv7poe6Ni8LeF3KYLm4HgjSO8lj8G/KALHsteWt5iteu0AxXzYa4WYYdcyt
> 8RkZOg2/x97vbwkM3wwJ3e9CfebDrOmsQ4BefiRGH+9UKIzbAgoLQ8Xya0XZrIUd
> 21EAy1qF1TSaiP2coIVCKo5mwzneBJxkQU5EJnMMWxsnYYdcL7SxTEhPwA73712S
> gWk6tlt959e6LpJaddKDAmIIxIXYhmrVFKvl7y/XHRZPdKhaz0rfC6Up/9MVthhL
> LGEOzRMJ4oF6IjfSi94dFC9CLtGm8s8l812Or9hvzudBU1ZfJbPIOJ1PAGFHWb8=
> =Z3dN
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack <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 <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack>
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : 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/ad283b70/attachment.html>

More information about the Openstack mailing list