[ patrole ] Understanding RBAC Permission Exceptions
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. 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 ? Why the expected results can be different from the actual ones? 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
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. 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 ? Why the expected results can be different from the actual ones? 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
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
---- On Mon, 12 Jul 2021 04:16:41 -0500 darumaseye <darumaseye@protonmail.com> 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. 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 ? Why the expected results can be different from the actual ones? Are there publicly available examples showing "Failure" values? In general, are there any publicly available test cases that i can study to understand this?
Thanks, Jacopo showing interest in Patrole project. Your understanding is right, API needs to enforce the same policy and default what patrole test expect. So in a normal or when the policy rule default value is changed then these test will not raise the 'RbacOverPermissionException' or 'RbacUnderPermissionException' as actual and expected are same. But when API stop or change the particular policy rule enforcement then test will start seeing these two exceptions depending on that change, For example: * "API A" enforce policy rule "policyA" with default value as "project member". This means users with "project member" (non-admin) roles will access the "API A". Test verify the same so test pass. * "API A" now changes their policy enforcement to: case1: Add a new policy rule "policyB" with default value as "admin". OR case2: Replace the "policyA" with "policyC" with default value as "admin" In the above cases, existing users with "project member" (non-admin) roles would not be able to access the "API A" anymore. And that is what test verify and test will start raising the "RbacUnderPermissionException". and in vice versa case, when policy change in API side has a wider default role than the previous policy, Test (negative test) will start raising "RbacOverPermissionException" Another case where Patrole tests play an important role is when policy names are changed. We usually change name with the old name still supported for at least one cycle, so if any API change their policy name without old name supported for the deprecation period then Patrole test will start capturing it. That way Patrole tests capture the things that can break the existing users. Also, we are looking for a maintainer in this project so any kind of help you can do will be beneficial. Please ping us on #openstack-qa IRC channel for involvement/improvement in this project. -gmann
I Would like to thank you very much in advance; Best Regards,
Jacopo
participants (3)
-
darumaseye
-
Ghanshyam Mann
-
Sean Mooney