No notifications for role grants using v2

[Brant Knudson]

If you use the v3 API to add or remove role grants, you get notifications that it happened, but if you use the v2.0 API, you don't get notifications.

Keystone needs to send notifications when the v2 API is used, also.

For example, start with devstack, then grant a role:

$ keystone user-role-add --user demo --tenant admin --role admin
   - gets a notification for identity.authenticate, but none for identity.created.role_assignment

Same for revoke:

$ keystone user-role-remove --user demo --tenant admin --role admin
   - gets a notification for identity.authenticate, but none for identity.deleted.role_assignment

v3 works fine:

$ curl -X PUT -H "X-Auth-Token: $TOKEN" http://localhost:5000/v3/projects/$PROJECT_ID/users/$USER_ID/roles/$ROLE_ID

$ curl -X DELETE -H "X-Auth-Token: $TOKEN" http://localhost:5000/v3/projects/$PROJECT_ID/users/$USER_ID/roles/$ROLE_ID

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/166934

[Brant Knudson (blk-u)]

Marking this as a security bug. A user can avoid the CADF audit record just by using the v2 API rather than the v3 API.

[Tristan Cacqueray (tristan-cacqueray)]

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.

[Jeremy Stanley (fungi)]

In attempting to determine whether this warrants a security advisory we should discuss the associated risks, intention, and any precedent it might set for issuance of future advisories. In essence, this looks like a potential detection bypass. In a multi-version-capable deployment a malicious actor could use the v2 API to hide role grant/remove activities in an effort to avoid creating an audit trail. This doesn't allow them to perform activities they would not normally be able. A few related questions to help classify this further:

Was this previously logged and then a regression introduced which caused it to stop logging, or was it merely added to the v3 API but never implemented for v2?

Is logging parity between API versions considered a security requirement, such that any new action logging added in newer API versions must necessarily also be included in earlier versions?

If we consider this a vulnerability, is there some standard we can consult identifying what activities must be logged so that any which aren't similarly qualify as vulnerabilities when we eventually discover them?

[Brant Knudson (blk-u)]

I don't think we ever issued notifications for v2 role assignment create or remove APIs. Here's the commit to add notifications to v3 role assignments: https://github.com/openstack/keystone/commit/a5a17d984375cf9afb9a5f01493db8da23d5e531

There are several v2 operations that emit audit notifications. For example, getting a token using the v2 API or creating a user using the v2 API emits an audit notification just like when the equivalent v3 API is used.

In the cases where both v2 and v3 emit audit notifications the code was written correctly -- the v2 and v3 controllers call the same method in the manager. In the case of role assignments, for some reason the v2 controller calls add_role_to_user_and_project whereas the v3 controller calls create_grant.

[Jeremy Stanley (fungi)]

In that case, assuming the v2 API has never logged these, I don't believe there's any need for us to issue a security advisory once it starts to do so. I'm open to counterarguments however.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/166934
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=2e859e17f97d78a4146e6bf4e7711bb1806c5ab1
Submitter: Jenkins
Branch: master

commit 2e859e17f97d78a4146e6bf4e7711bb1806c5ab1
Author: Brant Knudson <email address hidden>
Date: Mon Mar 23 12:26:50 2015 -0500

    Fix for notifications for v2 role grant/delete

    Notifications were not being sent when role grants were added or
    deleted using the v2 API.

    SecurityImpact

    Change-Id: I577d4435d551181298b23e713ed84f76d9f1ba3e
    Closes-Bug: #1435396

[Thierry Carrez (ttx)]

Agree with fungi