RBAC needs to be checked for stored-key orders

Bug #1446266 reported by Dave McCowan
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Barbican
Fix Released
High
Arun Kant

Bug Description

For the use case “Order a certificate based on a stored key”:

If a container is restricted by an ACL, then that should be enforced if a user tries to order a certificate based on that container.

It is not.

A fix should go it two places:

In TypeOrderValidator(), a check should be made that the requesting user has access to the referenced container.

In the worker, a second check should be made, in case the ACL has changed sinced validated.

Arun Kant (arukant)
Changed in barbican:
assignee: nobody → Arun Kant (arunkant-uws)
Revision history for this message
John Wood (john-wood-w) wrote :

I think this can be a simplified check since order are not covered by ACLs now, and therefore are still project-id based.

So I think if the stored key is not associated with the order's project-id, it should be rejected at API time (so no need to check this on the worker again later)

If that check passes on the API side, or the worker is now processing this order, a check is then made to see if the secret has an ACL associated with it. If it does, then I think initially we can reject this request as well.

We might relax this later and say that if the project-id is on the ACL for the stored key, then we allow the order to process. I say that because if a certificate/container is the created based on the stored key, then an attempt to GET that container using the project-id should probably succeed.

Revision history for this message
Arun Kant (arukant) wrote :

Based on barbican IRC discussion, this RBAC check is only going to be enforced at order submission request, not at worker level.

RBAC check will be similar to policy rule defined for container GET operation.

"container:get": "rule:container_non_private_read or rule:container_creator_user or rule:container_acl_read",

For worker logic, approach to full acl check implementation is not clear. Also what is expected behavior around copying acl for order created cert container . So its going to be discussed in Kilo Summit and then its going to implemented accordingly.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to barbican (master)

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

Changed in barbican:
status: New → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to barbican (master)

Reviewed: https://review.openstack.org/176558
Committed: https://git.openstack.org/cgit/openstack/barbican/commit/?id=7dc48c5f73b643a8afbaf0dfa1a9b8de1c1807f8
Submitter: Jenkins
Branch: master

commit 7dc48c5f73b643a8afbaf0dfa1a9b8de1c1807f8
Author: Arun Kant <email address hidden>
Date: Wed Apr 22 17:27:03 2015 -0700

    Adding ACL check when new stored key order is submitted

    Addressing case when new stored key order is requested and container used in
    order is marked private via ACL. In that case, only creator user of container
    and user(s) with 'read' ACL on container can request new order. For new order,
    existing checks are still valid. 1) order project and container project needs
    to be same. 2) user need to have 'admin' or 'creator' role as defined in
    orders:post policy rule.

    Change-Id: I6b21aec8cc62de2ed6b1cc1ee878d756892c414d
    Closes-bug: #1446266

Changed in barbican:
status: In Progress → Fix Committed
Changed in barbican:
importance: Undecided → High
milestone: none → liberty-1
Changed in barbican:
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in barbican:
milestone: liberty-1 → 1.0.0
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.