Domain admin has access to service Admin API with policy.v3cloudsample.json

[Mohammed Naser]

Keystone has a sample policy file to create a concept of domains per customer, with a domain admin that manages users and tenants inside that domain.

https://github.com/openstack/keystone/commits/master/etc/policy.v3cloudsample.json

In this policy, the domain admin role (a user who manages that domain) would get the "admin" role assigned to them. However, with the "admin" role assigned to them, they can make requests to the admin_api (in this case, the Nova example).

https://github.com/openstack/nova/blob/master/nova/policies/base.py#L18-L28

I have done a fair bit of checking but I believe that a domain admin can get full access to the admin_api (or be able to create a user with an "admin" role and get access to the entire cloud). I believe this affects all other projects and users of this policy would not be aware at the level of access given to a domain admin.

Perhaps the file can be revised to use a role like "domain_admin" and Keystone would have a setting of "reserved role names" which cannot be used (e.g. block the role "admin" from being created in a domain).

Please forgive me in advance if this is not a security issue and a lack of understanding (I hope it is), but I have done a fair amount of research on this so far and it seems like getting access to that `admin` role is an issue.

[Jeremy Stanley (fungi)]

Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.

[Tristan Cacqueray (tristan-cacqueray)]

@horizon-coresec: please triage this bug report.

[Lance Bragstad (lbragstad)]

This specific situation is related to the long-standing admin-ness issue we have across OpenStack [0]. We do have fixes in flight (which are public) that help mitigate this [1]. The work to fix the issues here requires coordination across several projects.

[0] https://bugs.launchpad.net/keystone/+bug/968696
[1] http://lists.openstack.org/pipermail/openstack-dev/2017-May/117419.html

[Mohammed Naser (mnaser)]

It seems like other users are seeing this issue so I'm not sure if this should be addressed as part of an advisory or something to avoid someone with malicious intent finding out that they might have admin access to a cloud.

http://lists.openstack.org/pipermail/openstack/2017-May/044977.html

[Jeremy Stanley (fungi)]

Is the fundamental issue here basically public knowledge (between mitigations in flight, similar questions on mailing lists, et cetera)? Handling this report becomes a lot simpler if there's no strong reason to maintain an embargo.

[Lance Bragstad (lbragstad)]

I agree with Jeremy's statement in comment #5.

[Morgan Fainberg (mdrnstm)]

I agree with #5 and there is no strong reason to maintain an embargo.

[Jeremy Stanley (fungi)]

Thanks, switching to public security.

[Jeremy Stanley (fungi)]

Should we be considering this a duplicate, like for bug 968696 maybe? Also what is the prognosis for actually fixing it? Wondering if it falls into a redesign situation along the lines of report class B2 ("A vulnerability without a complete fix yet, security note for all versions, e.g., poor architecture / design") in our taxonomy? https://security.openstack.org/vmt-process.html#incident-report-taxonomy

[Tristan Cacqueray (tristan-cacqueray)]

Should we report the seemingly insecure policy.v3cloudsample.json to bug 968696 or is this file going to be fixed separately ?

I agree with class B2 because the proposed solution seems to alter the default policy.json which is likely incompatible with stable branch backport policies. Though whenever a solution can be applied to the stable branches then this could be switched to class A.

Also this looks like a variant of https://wiki.openstack.org/wiki/OSSN/OSSN-0010

[Lance Bragstad (lbragstad)]

The fix consists of the following:

  - allowing users to have global role assignments in keystone
  - allowing users to ask for globally scoped tokens

At that point, it's up to the consuming projects to interpret global scope in a consistent way when checking the scope of the request (e.g. is the instance being acted on in the project that the token is scoped to). Each project will need to understand which operations in their API need to check for global scope (e.g. listing all instances in nova regardless of the project they are in is a good example of a request that should require global scope). The global role bits are being implemented in keystone as we speak [0], but they won't be backportable.

As far as the policy.v3cloudsample.json file. Its existence was partially due to the issue I just described. The goal of the policy.v3cloudsample.json file was to provide a sample policy file that understood the differences between a cloud administrator and various roles applied to projects or domains. It requires deployers to create some new roles for their deployment. I think the policy.v3cloudsample.json is something that can dissolve over time, as we make it easier for projects to change default roles required for various operations. OpenStack should have sane default roles out-of-the-box, and when we get to that point, policy.v3cloudsample.json shouldn't be needed.

Hopefully this helps clarify the current approach we're taking.

[0] https://review.openstack.org/#/c/481781/

[Jeremy Stanley (fungi)]

Okay, so somewhere between the aforementioned B2 ("A vulnerability without a complete fix yet...") and B1 ("A vulnerability that can only be fixed in master, security note for stable branches, e.g., default config value is insecure"). I'll go ahead and mark our advisory task "won't fix" and let the OSSN editors decide how and when they might want to write this up as a note.

[Lance Bragstad (lbragstad)]

Just to give a quick status update on the feature that will help fix this. We do have the system-scope implementation going through review now [0]. We also have a series of patches to keystone (and some other projects) that attempt to define the scope type for each policy/operation [1].

I've been tracking parts of this fix against bug 968696.

[0] https://review.openstack.org/#/q/(status:merged+OR+status:open)+project:openstack/keystone+branch:master+topic:bp/system-scope
[1] https://review.openstack.org/#/q/(status:merged+OR+status:open)+project:openstack/keystone+branch:master+topic:add-scope-types

[Lance Bragstad (lbragstad)]

Do we want to track the keystone bits as duplicate of bug 968696 or should this be triaged/tracked separately?

[Jeremy Stanley (fungi)]

Seems fine to me to mark this one as a duplicate at this point.

[Lance Bragstad (lbragstad)]

Done. Thanks for the follow-up, Jeremy.