<div dir="ltr"><div>I take issue with choice of words, in your note. The key here is around this statement:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Essentially, this means that any token for a particular user can indirectly be used to perform any action that user is allowed to perform.</blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.<br><br>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.</div><div><br></div><div>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.)<br><br>Sounds like you want to *enhance* security via introducing control over capabilities.</div><div><br></div><div><br></div><div>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?</div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 17, 2014 at 8:18 AM, Nathan Kinder <span dir="ltr"><<a href="mailto:nkinder@redhat.com" target="_blank">nkinder@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Keystone token scoping provides no security benefit<br>
- ---<br>
<br>
### Summary ###<br>
Keystone provides "scoped" tokens that are constrained to use by a<br>
single project. A user may expect that their scoped token can only be<br>
used to perform operations for the project it is scoped to, which is not<br>
the case. A service or other party who obtains the scoped token can use<br>
it to obtain a token for a different authorized scope, which may be<br>
considered a privilege escalation.<br>
<br>
### Affected Services / Software ###<br>
Keystone, Diablo, Essex, Folsom, Grizzly, Havana, Icehouse, Juno, Kilo<br>
<br>
### Discussion ###<br>
This is not a bug in keystone, it's a design feature that some users may<br>
expect to bring security enhancement when it does not. The OSSG is<br>
issuing this security note to highlight the issue.<br>
<br>
Many operations in OpenStack will take a token from the user and pass it<br>
to another service to perform some portion of the intended operation.<br>
This token is very powerful and can be used to perform many actions for<br>
the user. Scoped tokens appear to limit their use to the project and<br>
roles they were granted for but can also be used to request tokens with<br>
other scopes. It's important to note that this only works with currently<br>
valid tokens. Once a token expires it cannot be used to gain a new<br>
token.<br>
<br>
Token scoping helps avoid accidental leakage of tokens because using<br>
tokens with other services requires the extra step of requesting a new<br>
re-scoped token from keystone. Scoping can help with audit trails and<br>
promote good code practices. There's currently no way to create a<br>
tightly scoped token that cannot be used to request a re-scoped token. A<br>
scoped token cannot be relied upon to restrict actions to only that<br>
scope.<br>
<br>
### Recommended Action ###<br>
Users and deployers of OpenStack must not rely on the scope of tokens<br>
to limit what actions can be performed using them.<br>
<br>
Concerned users are encouraged to read (OSSG member) Nathan Kinder's<br>
blog post on this issue and some of the potential future solutions.<br>
<br>
### Contacts / References ###<br>
Nathan Kinder on Token Scoping : <a href="https://blog-nkinder.rhcloud.com/?p=101" target="_blank">https://blog-nkinder.rhcloud.com/?p=101</a><br>
This OSSN : <a href="https://wiki.openstack.org/wiki/OSSN/OSSN-0042" target="_blank">https://wiki.openstack.org/wiki/OSSN/OSSN-0042</a><br>
Original LaunchPad Bug : <a href="https://bugs.launchpad.net/ossn/+bug/1341816" target="_blank">https://bugs.launchpad.net/ossn/+bug/1341816</a><br>
OpenStack Security ML : <a href="mailto:openstack-security@lists.openstack.org">openstack-security@lists.openstack.org</a><br>
OpenStack Security Group : <a href="https://launchpad.net/~openstack-ossg" target="_blank">https://launchpad.net/~openstack-ossg</a><br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1<br>
<br>
</div></div>iQEcBAEBAgAGBQJUkazSAAoJEJa+6E7Ri+EVwCoIAINTtZHphJp++r1i7CwAJ+TD<br>
LUyLIFv7poe6Ni8LeF3KYLm4HgjSO8lj8G/KALHsteWt5iteu0AxXzYa4WYYdcyt<br>
8RkZOg2/x97vbwkM3wwJ3e9CfebDrOmsQ4BefiRGH+9UKIzbAgoLQ8Xya0XZrIUd<br>
21EAy1qF1TSaiP2coIVCKo5mwzneBJxkQU5EJnMMWxsnYYdcL7SxTEhPwA73712S<br>
gWk6tlt959e6LpJaddKDAmIIxIXYhmrVFKvl7y/XHRZPdKhaz0rfC6Up/9MVthhL<br>
LGEOzRMJ4oF6IjfSi94dFC9CLtGm8s8l812Or9hvzudBU1ZfJbPIOJ1PAGFHWb8=<br>
=Z3dN<br>
-----END PGP SIGNATURE-----<br>
<br>
_______________________________________________<br>
Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
Post to     : <a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a><br>
Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
</blockquote></div><br></div>