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