Open Stack

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

Cheers,
Morgan Fainberg

> 
> 
>  
> 
> 
> 
> 
>  
> 
> On Wed, Dec 17, 2014 at 8:18 AM, Nathan Kinder <nkinder at redhat.com <mailto:nkinder at redhat.com>> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iQEcBAEBAgAGBQJUkazSAAoJEJa+6E7Ri+EVwCoIAINTtZHphJp++r1i7CwAJ+TD
> LUyLIFv7poe6Ni8LeF3KYLm4HgjSO8lj8G/KALHsteWt5iteu0AxXzYa4WYYdcyt
> 8RkZOg2/x97vbwkM3wwJ3e9CfebDrOmsQ4BefiRGH+9UKIzbAgoLQ8Xya0XZrIUd
> 21EAy1qF1TSaiP2coIVCKo5mwzneBJxkQU5EJnMMWxsnYYdcL7SxTEhPwA73712S
> gWk6tlt959e6LpJaddKDAmIIxIXYhmrVFKvl7y/XHRZPdKhaz0rfC6Up/9MVthhL
> LGEOzRMJ4oF6IjfSi94dFC9CLtGm8s8l812Or9hvzudBU1ZfJbPIOJ1PAGFHWb8=
> =Z3dN
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> 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>