openstack-attic/openstack-security-notes
Code Issues Proposed changes

Correct workaround in OSSN-0013

Browse Source 
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
This commit is contained in:
Nathan Kinder 2014-06-05 15:43:53 -07:00
parent 29305c9fe5
commit 5f5202470c
1 changed files with 54 additions and 48 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

102
notes/OSSN-0013
View File

@ -12,65 +12,71 @@ Glance, Folsom, Grizzly
### Discussion ### ### Discussion ###
Glance property protections limit the users who can perform CRUD operations on 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 a Glance property to those in specific roles. When the property protections
would reject an action and a less specific rule that comes after that accepts rules are processed in the Folsom and Grizzly OpenStack releases, a matching
the action, then the action is accepted even though one may expect it to be rule will only stop the processing of subsequent rules if it authorizes the
rejected. 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 This bug only affects the use of user-roles in Glance. It does not occur when
policies are used to determine property protections. 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 ### ### 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 Users of affected releases should avoid using multiple rules that would match
property-protections.conf to place the most open permissions at the start of the same property. Specifically, wildcard rules should be avoided unless they
the configuration and more restrictive ones at the end, as demonstrated below. are the most restricive rules defined.
--- Begin Example --- If a permissive rule is needed that is intended to match all properties that
/etc/Glance/property-protections.conf are not matched by other rules, a carefully crafted regular expression should
[.*] be used instead of a wildcard as demonstrated below.
create = @
read = @
update = @
delete = @
[^foo_property$] --- begin example property-protections.conf snippet ---
create = @ [^provider_.*$]
read = @ create = admin
read = admin,_member_
update = admin update = admin
delete = admin delete = admin
--- End Example ---
In the above example, '.*' and 'foo_property' entries in the protections file [^((?!provider_).)*$]
have been reversed, ensuring that the more restrictive permissions required for create = _member_
'foo_property' are applied after the wider '.*' permissions and assuring that read = _member_
'update' and 'delete' operations are restricted to only users with in the update = _member_
'admin' role. 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 Configuration files with multiple property protection entries set should be
tested to ensure that CRUD actions are constrained in the way the administrator tested to ensure that CRUD actions are constrained in the way the administrator