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).
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. You want to be explicit that you are *not* changing existing behavior. (Or you are, and can justify breaking an unknown number of applications.) 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.) 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. On Wed, Dec 17, 2014 at 10:42 AM, Nathan Kinder <[email protected]> wrote: > > > > On 12/17/2014 10:16 AM, Preston L. Bannister 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 that the current behavior is not a bug. It is a > behavior that can be misleading though, as one might assume that an > intercepted token can only be used to perform actions that are allowed > by that specific token. This notes is pointing out that the assumption > that token scope has a security property is incorrect. > > > > > 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. > > Yes, this is correct (though these potential enhancements are not the > intent of the security note). > > > > > 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. > > > > 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. > > Yes, absolutely (though it's best to avoid the word 'trust' since that > has a very specific meaning in Keystone). > > Ultimately, being able to request what roles you want a token to contain > would be ideal. I describe some of this in my blog post that is > referenced in the security note. > > For this to be useful, the end-user requesting a token needs to have > some idea of what roles are required to perform a particular action. > This requires policy related enhancements, which have had some > discussion on the development mailing list as well as in the design > sessions at the Summit in Paris. > > > > > 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.) > > Yes, these are the policy related enhancements I was mentioning. Being > able to have API calls to answer the following questions would be useful > for this: > > - What roles to I need to perform action 'x'? > - What actions can I perform using token 'x'? > > This is similar to things like the 'get effective rights' control in LDAP. > > > > > Sounds like you want to *enhance* security via introducing control over > > capabilities. > > That is correct, but the intent of this security note is to raise > awareness of how Keystone token scope works since it can be easily > misunderstood form a security perspective. > > > > > > > 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? > > Absolutely. Both of the topics mentioned above have been discussed by > the Keystone development team. There are various pieces that need to > fall into place first, but there are efforts underway to improve things > in this area. > > Thanks, > -NGK > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Dec 17, 2014 at 8:18 AM, Nathan Kinder <[email protected] > > <mailto:[email protected]>> wrote: > > > > 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 > > This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0042 > > Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1341816 > > OpenStack Security ML : [email protected] > > <mailto:[email protected]> > > OpenStack Security Group : https://launchpad.net/~openstack-ossg > > > > _______________________________________________ > > Mailing list: > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > Post to : [email protected] > > <mailto:[email protected]> > > Unsubscribe : > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > >
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : [email protected] Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
