From 5f5202470c1ecb48ff70f305074c7cfac05202b6 Mon Sep 17 00:00:00 2001 From: Nathan Kinder Date: Thu, 5 Jun 2014 15:43:53 -0700 Subject: [PATCH] Correct workaround in OSSN-0013 The workaround previously described in OSSN-0013 was not correct due to a misunderstanding in the behavior of the original bug. This update adds a workaround that has been tested in Havana, and it also provides a more clear description about Glance's broken behavior with regards to processing property protections rules. Related-Bug: #1271426 Change-Id: Ice8f6d31345c308f09ee14b55053d205d9f57e69 --- notes/OSSN-0013 | 102 +++++++++++++++++++++++++----------------------- 1 file changed, 54 insertions(+), 48 deletions(-) diff --git a/notes/OSSN-0013 b/notes/OSSN-0013 index 7ca4955..c896d56 100644 --- a/notes/OSSN-0013 +++ b/notes/OSSN-0013 @@ -12,65 +12,71 @@ 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. +a Glance property to those in specific roles. When the property protections +rules are processed in the Folsom and Grizzly OpenStack releases, a matching +rule will only stop the processing of subsequent rules if it authorizes the +attempted action. If there is a matching rule that would reject an action that +is followed by another matching rule that would accept the action, then the +action is accepted even though one may expect it to be rejected. + +In the following policy-protections.conf example, the desired result is to +restrict 'update' and 'delete' permissions for any property beginning with +'provider_' to only users with the 'admin' role. + +--- begin example property-protections.conf snippet --- +[^provider_.*$] +create = admin +read = admin,_member_ +update = admin +delete = admin + +[.*] +create = _member_ +read = _member_ +update = _member_ +delete = _member_ +--- end example property-protections.conf snippet --- + +Due to the way that the rules are processed in the Folsom and Grizzly OpenStack +releases, the admin restriction for properties beginning with 'provider_' is +nullified by the '.*' permissions since it also matches the same properties. +This results in all users with the '_member_' role being allowed the 'create', +'update', and 'delete' permissions on properties beginning with 'provider_', +which is not what was intended. 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. - ---- Begin Example --- -/etc/glance/property-protections.conf -[^foo_property$] -create = @ -read = @ -update = admin -delete = admin - -[.*] -create = @ -read = @ -update = @ -delete = @ ---- End Example --- - -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. +This issue has been fixed in Havana (Glance 2013.2.2) and subsequent releases +by changing the property protections rule processing to stop at the first rule +that matches the property, even if it does not allow the attempted action. -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. +Users of affected releases should avoid using multiple rules that would match +the same property. Specifically, wildcard rules should be avoided unless they +are the most restricive rules defined. ---- Begin Example --- -/etc/Glance/property-protections.conf -[.*] -create = @ -read = @ -update = @ -delete = @ +If a permissive rule is needed that is intended to match all properties that +are not matched by other rules, a carefully crafted regular expression should +be used instead of a wildcard as demonstrated below. -[^foo_property$] -create = @ -read = @ +--- begin example property-protections.conf snippet --- +[^provider_.*$] +create = admin +read = admin,_member_ update = admin delete = admin ---- End Example --- -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. +[^((?!provider_).)*$] +create = _member_ +read = _member_ +update = _member_ +delete = _member_ +--- end example property-protections.conf snippet --- + +In the above example, 'create', 'update', and 'delete' operations are only +allowed for users with the '_member_' role for properties that do not begin +with 'provider_'. Configuration files with multiple property protection entries set should be tested to ensure that CRUD actions are constrained in the way the administrator