| 2014-03-13 09:32:28 |
Henry Nash |
description |
Today we allow the domain_id in User, Group and Project entities to be updated….effectively moving the entity between domains. With today's policy capability this represents a potential security hole if you are trying to enforce strict domain admin type of roles. We should allow a cloud provider to disable this current update ability…and make the domain_id attribute immutable in the same way we do for the id of the entity. |
Today we allow the domain_id in User, Group and Project entities to be updated….effectively moving the entity between domains. With today's policy capability this represents a potential security hole if you are trying to enforce strict domain admin type of roles. We should allow a cloud provider to disable this current update ability…and make the domain_id attribute immutable in the same way we do for the id of the entity.
Here's a recipe for how to create this potential security hole using the v3 policy sample file:
- Have a user with role 'admin' on the domain_A (this makes them a "domain admin")
- Update their user entity (or any other user entity) with {'domain_id': domain_B}. This will succeed, even though the goal of the v3 policy sample file is to restrict the access for such a user is to only objects domain_A
- The user is now part of domain_B
- The above does not actually yet give the user ability to authenticate to domain_B (since they do not have a role on that domain)…but it perhaps lays the ground work for some other attack to enable that |
|
| 2014-03-13 09:33:03 |
Henry Nash |
description |
Today we allow the domain_id in User, Group and Project entities to be updated….effectively moving the entity between domains. With today's policy capability this represents a potential security hole if you are trying to enforce strict domain admin type of roles. We should allow a cloud provider to disable this current update ability…and make the domain_id attribute immutable in the same way we do for the id of the entity.
Here's a recipe for how to create this potential security hole using the v3 policy sample file:
- Have a user with role 'admin' on the domain_A (this makes them a "domain admin")
- Update their user entity (or any other user entity) with {'domain_id': domain_B}. This will succeed, even though the goal of the v3 policy sample file is to restrict the access for such a user is to only objects domain_A
- The user is now part of domain_B
- The above does not actually yet give the user ability to authenticate to domain_B (since they do not have a role on that domain)…but it perhaps lays the ground work for some other attack to enable that |
Today we allow the domain_id in User, Group and Project entities to be updated….effectively moving the entity between domains. With today's policy capability this represents a potential security hole if you are trying to enforce strict domain admin type of roles. We should allow a cloud provider to disable this current update ability…and make the domain_id attribute immutable in the same way we do for the id of the entity.
Here's a recipe for how to create this potential security hole using the v3 policy sample file:
- Have a user with role 'admin' on the domain_A (this makes them a "domain admin")
- They try and update their user entity (or any other user entity) with {'domain_id': domain_B}. This will succeed, even though the goal of the v3 policy sample file is to restrict the access for such a user is to only objects domain_A
- The user is now part of domain_B
- The above does not actually yet give the user ability to authenticate to domain_B (since they do not have a role on that domain)…but it perhaps lays the ground work for some other attack to enable that |
|
