Open Stack

On Mon, 2021-07-12 at 09:16 +0000, darumaseye wrote:
> Hello,
> I am a researcher studying security of the Openstack's Policies.
> I'm very interested in the Patrole project and I would like to ask you some questions.
before you read the rest of my responce ill point out im not a security exprect and or an expert ofn patrole/oslo.policy
but i belive i know the gerneral reason why they can differ.
> In the documentation it is stated that Patrole compares two different types of results:
> - an expected one ( derived from oslo.policy )
> - an actual one ( derived from an actual request to the API ).
> Given that, Patrole's tests can return 3 different values:
> 1) "Success" if actual result and expected result are both True or both False;
> 2) "RbacOverPermissionException" if actual result is True but expected result is False;
> 3) "RbacUnderPermissionException" in the other case.
> 
> I can't understand in which cases the tests can return a value different from "Success".
> As far as I know, an API call should always be validated internally by oslo.policy's rules, before being allowed.
> So, in order for an API call to be accepted, oslo.policy's rules must allow that API call.
> It seems to me that the "expected" result ( derived from oslo.policy ) is always included in the actual result.
> Hoping that everything I said is correct, I would like to ask you:
> What issue is allowing such a strange behavior in Openstack APIs ?
in some older project like nova we in rare cases still have some restriciton enforced at the DB layer that
ment if you lossened the policy the db would stould still reject it. i cant recall the explict case but there
was at least one instnace of that.
> Why the expected results can be different from the actual ones?
not all projects support all the feature of oslo policy.
specfically not all project support the new standard personas in the secure rback work or support system scopes
so if you try to define policy rules using those featuer it may or may not work.

for example if a project does not support the distinction between project admin and system admin then if i create
a project admin token and use it on service a the does support that it will provide limited admin operatiosn but if
i use it on another service directly or indirectly it will provide global admin access. the inverse is also true
a system admin token in principal shold be able to do anything a global admin could do when the serure rbac feature is
disabeld but due to impleation detail in nova and other project it curretly can call any api the required the keystone middleware
context to contain a project id.  meanign a system admin with secure rbac enabled cannot stop a vm today  where as a project admin
 or porject member token can. that is because the nova api r equires a project id to stop a vm but a system admin token is not assocated
with a porject. that a case where the token has the required permissions but does not meet the preconditions of the api.
https://review.opendev.org/c/openstack/keystone-specs/+/787640 will hopefully provide a way to support this usecase.
im not sure what will be returned in this configuration today.


im not sure if any of that is helpful but those are the kind of things that i would expefct to lead to either a failed api call
or an under or over permission excptions. i have not looked at how  Patrole versions its test either so ist possible that projects
may change a policy default in a release and  Patrole might see that as an under or  over permission issue depending on what that change was.

> Are there publicly available examples showing "Failure" values?
> In general, are there any publicly available test cases that i can study to understand this?
> 
> I Would like to thank you very much in advance;
> Best Regards,
> 
> Jacopo