<div dir="ltr">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). <div><br></div><div>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. <div><br></div><div>You want to be explicit that you are *not* changing existing behavior. (Or you are, and can justify breaking an unknown number of applications.)<br><div><br></div><div>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.)</div><div><br></div><div><div><br></div><div>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.</div></div></div></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 17, 2014 at 10:42 AM, Nathan Kinder <span dir="ltr"><<a href="mailto:nkinder@redhat.com" target="_blank">nkinder@redhat.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 12/17/2014 10:16 AM, Preston L. Bannister wrote:<br>
> I take issue with choice of words, in your note. The key here is around<br>
> this statement:<br>
><br>
>     Essentially, this means that any token for a particular user can<br>
>     indirectly be used to perform any action that user is allowed to<br>
>     perform.<br>
><br>
><br>
> As we are talking about actions the "user is allowed to perform", then<br>
> we are *not* talking about "privilege escalation". The current behavior<br>
> is *not* a malfunction that needs fixing.<br>
<br>
</span>You are correct that the current behavior is not a bug.  It is a<br>
behavior that can be misleading though, as one might assume that an<br>
intercepted token can only be used to perform actions that are allowed<br>
by that specific token.  This notes is pointing out that the assumption<br>
that token scope has a security property is incorrect.<br>
<span class=""><br>
><br>
> Leaving aside the slightly alarming use of words, what you seem to be<br>
> proposing is a *new* behavior in Keystone. It sounds like you are<br>
> proposing a means of creating a scoped token that *cannot* be used to<br>
> request another token with a different scope.<br>
<br>
</span>Yes, this is correct (though these potential enhancements are not the<br>
intent of the security note).<br>
<span class=""><br>
><br>
> The use case that comes to mind is limited trust. You want to pass a<br>
> token to another service, but you want to limit that service to *less*<br>
> than the full range of permissions for the user.<br>
><br>
> If the use case is limited trust, then changing the project scope is<br>
> only one aspect. You might also want to subtract other permissions held<br>
> by the user.<br>
<br>
</span>Yes, absolutely (though it's best to avoid the word 'trust' since that<br>
has a very specific meaning in Keystone).<br>
<br>
Ultimately, being able to request what roles you want a token to contain<br>
would be ideal.  I describe some of this in my blog post that is<br>
referenced in the security note.<br>
<br>
For this to be useful, the end-user requesting a token needs to have<br>
some idea of what roles are required to perform a particular action.<br>
This requires policy related enhancements, which have had some<br>
discussion on the development mailing list as well as in the design<br>
sessions at the Summit in Paris.<br>
<span class=""><br>
><br>
> The more general case here is the ability to enumerate and enable (if<br>
> allowed) or disable capabilities. (Windows has some rather elaborate<br>
> APIs around this, that I have not visited in several years.)<br>
<br>
</span>Yes, these are the policy related enhancements I was mentioning.  Being<br>
able to have API calls to answer the following questions would be useful<br>
for this:<br>
<br>
- What roles to I need to perform action 'x'?<br>
- What actions can I perform using token 'x'?<br>
<br>
This is similar to things like the 'get effective rights' control in LDAP.<br>
<span class=""><br>
><br>
> Sounds like you want to *enhance* security via introducing control over<br>
> capabilities.<br>
<br>
</span>That is correct, but the intent of this security note is to raise<br>
awareness of how Keystone token scope works since it can be easily<br>
misunderstood form a security perspective.<br>
<span class=""><br>
><br>
><br>
> I have not spent a lot of time with Keystone, some perhaps I missed<br>
> something. I do not see anything along that line mentioned. Is there<br>
> interest in introducing control over capabilities in Keystone tokens?<br>
<br>
</span>Absolutely.  Both of the topics mentioned above have been discussed by<br>
the Keystone development team.  There are various pieces that need to<br>
fall into place first, but there are efforts underway to improve things<br>
in this area.<br>
<br>
Thanks,<br>
-NGK<br>
<span class=""><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> On Wed, Dec 17, 2014 at 8:18 AM, Nathan Kinder <<a href="mailto:nkinder@redhat.com">nkinder@redhat.com</a><br>
</span><span class="">> <mailto:<a href="mailto:nkinder@redhat.com">nkinder@redhat.com</a>>> wrote:<br>
><br>
> Keystone token scoping provides no security benefit<br>
</span><div><div class="h5">> ---<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>
</div></div>> <mailto:<a href="mailto:openstack-security@lists.openstack.org">openstack-security@lists.openstack.org</a>><br>
<span class="">> OpenStack Security Group : <a href="https://launchpad.net/~openstack-ossg" target="_blank">https://launchpad.net/~openstack-ossg</a><br>
><br>
</span><span class="">>     _______________________________________________<br>
>     Mailing list:<br>
>     <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>
</span>>     <mailto:<a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a>><br>
>     Unsubscribe :<br>
>     <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
><br>
><br>
</blockquote></div></div>