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

Adds OSSN-0013

Browse Source 
This adds OSSN-0013 addressing an issue with the way Glance property
protections are processed. In some deployments it is possible that a
configuration will allow actions that the administrator had intended
to restrict, unless permissions are defined in a careful order.

Change-Id: Ib149f2559659702f21793c3394bd0791352e18b3
Closes-Bug: #1271426
This commit is contained in:
Robert Clark 2014-05-02 09:41:26 +01:00
parent 3e3088b00d
commit 407fb8f198
1 changed files with 86 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

86
notes/OSSN-0013 Normal file
View File

@ -0,0 +1,86 @@
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.
--- 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.
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.
--- Begin Example ---
/etc/Glance/property-protections.conf
[.*]
create = @
read = @
update = @
delete = @
[^foo_property$]
create = @
read = @
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.
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