> On Dec 17, 2014, at 1:16 PM, Preston L. Bannister <[email protected]> > 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 <[email protected] > <mailto:[email protected]>> 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 : [email protected] > <mailto:[email protected]> > 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 : [email protected] > <mailto:[email protected]> > 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 : [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
