Difference between revisions of "OSSN/OSSN-0013"
Robert-clark (talk | contribs) |
|||
| Line 1: | Line 1: | ||
| + | __NOTOC__ | ||
== Some versions of Glance do not apply property protections as expected == | == Some versions of Glance do not apply property protections as expected == | ||
| Line 21: | Line 22: | ||
In the following policy-protections.conf example, the desired result is to | In the following policy-protections.conf example, the desired result is to | ||
| − | restrict 'update' and 'delete' permissions for 'foo_property' to only users | + | restrict ''update'' and ''delete'' permissions for ''foo_property'' to only users |
| − | with the 'admin' role. | + | with the ''admin'' role. |
| − | |||
/etc/glance/property-protections.conf | /etc/glance/property-protections.conf | ||
[^foo_property$] | [^foo_property$] | ||
| Line 37: | Line 37: | ||
update = @ | update = @ | ||
delete = @ | delete = @ | ||
| − | |||
Due to the order that the rules are applied in the Folsom and Grizzly OpenStack | Due to the order that the rules are applied in the Folsom and Grizzly OpenStack | ||
| − | releases, the admin restriction for 'foo_property' is nullified by the '.*' | + | releases, the admin restriction for ''foo_property'' is nullified by the ''.*'' |
| − | permissions. This results in all roles being allowed the 'update' and 'delete' | + | permissions. This results in all roles being allowed the ''update'' and ''delete'' |
| − | permissions on 'foo_property', which is not what was intended. | + | permissions on ''foo_property'', which is not what was intended. |
=== Recommended Actions === | === Recommended Actions === | ||
| Line 51: | Line 50: | ||
the configuration and more restrictive ones at the end, as demonstrated below. | the configuration and more restrictive ones at the end, as demonstrated below. | ||
| − | |||
/etc/Glance/property-protections.conf | /etc/Glance/property-protections.conf | ||
[.*] | [.*] | ||
| Line 64: | Line 62: | ||
update = admin | update = admin | ||
delete = admin | delete = admin | ||
| − | |||
| − | In the above example, '.*' and 'foo_property' entries in the protections file | + | In the above example, ''.*'' and ''foo_property'' entries in the protections file |
have been reversed, ensuring that the more restrictive permissions required for | have been reversed, ensuring that the more restrictive permissions required for | ||
| − | 'foo_property' are applied after the wider '.*' permissions and assuring that | + | ''foo_property'' are applied after the wider ''.*'' permissions and assuring that |
| − | 'update' and 'delete' operations are restricted to only users with in the | + | ''update'' and ''delete'' operations are restricted to only users with in the |
| − | 'admin' role. | + | ''admin'' role. |
Configuration files with multiple property protection entries set should be | Configuration files with multiple property protection entries set should be | ||
Revision as of 22:35, 7 May 2014
Some versions of Glance do not apply property protections as expected
Summary
Tom Leaman reported an issue to the OpenStack mailing list that affects Glance property protections. A permissive property setting in the Glance property protections configuration file will override any previously set stricter ones.
Affected Services / Software
Glance, Folsom, Grizzly
Discussion
Glance property protections limit the users who can perform CRUD operations on a Glance property to those in specific roles. If there is a specific rule that would reject an action and a less specific rule that comes after that accepts the action, then the action is accepted even though one may expect it to be rejected.
This bug only affects the use of user-roles in Glance. It does not occur when policies are used to determine property protections.
In the following policy-protections.conf example, the desired result is to restrict update and delete permissions for foo_property to only users with the admin role.
/etc/glance/property-protections.conf [^foo_property$] create = @ read = @ update = admin delete = admin [.*] create = @ read = @ update = @ delete = @
Due to the order that the rules are applied in the Folsom and Grizzly OpenStack releases, the admin restriction for foo_property is nullified by the .* permissions. This results in all roles being allowed the update and delete permissions on foo_property, which is not what was intended.
Recommended Actions
This issue has been fixed in Havana (Glance 2013.2.2) and subsequent releases.
Users of affected releases should review and reorder the entries in property-protections.conf to place the most open permissions at the start of the configuration and more restrictive ones at the end, as demonstrated below.
/etc/Glance/property-protections.conf [.*] create = @ read = @ update = @ delete = @ [^foo_property$] create = @ read = @ update = admin delete = admin
In the above example, .* and foo_property entries in the protections file have been reversed, ensuring that the more restrictive permissions required for foo_property are applied after the wider .* permissions and assuring that update and delete operations are restricted to only users with in the admin role.
Configuration files with multiple property protection entries set should be tested to ensure that CRUD actions are constrained in the way the administrator intended.
Contacts / References
- This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0013
- Original Launchpad Bug : https://bugs.launchpad.net/glance/+bug/1271426
- Original Report : http://lists.openstack.org/pipermail/openstack-dev/2014-January/024861.html
- Glance Property Protections : https://wiki.openstack.org/wiki/Glance-property-protections
- OpenStack Security ML : openstack-security@lists.openstack.org
- OpenStack Security Group : https://launchpad.net/~openstack-ossg
