---- 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