API SIG and Neutron communities, TL;DR ----------------------- For API requests that specify boolean attributes to the request, we check "are you allowed to specify this attribute" before we check "would specifying this argument make any difference". I am proposing to change that so users can specify things forbidden by policy as long as the attribute specified equals the default and therefore the result would be the same as if it had not been specified. Are there any security problems with that? Long-winded explanation ----------------------- I would like your opinion on the potential security impact of a change I am proposing to the Neutron mechanism for assertion of oslo.policy. In response to an operator concern I proposed a change [1] that would exempt oslo.policy checks under one specific condition: if the request specifies a boolean attribute that matches a configured default. The way Neutron is currently coded, API requests have the oslo.policy check - "are you allowed to ask for X" before anything else about the request is processed. For those not familiar with it, oslo.polcy additionally provides the ability to control arguments within that request, so that you can permit only some users to use those arguments. For example, usually permissions to create a network are pretty broad but you must me admin to create a network and specify if it will be shared. The feedback that I got was that this was frustrating for users and some operators. The distinction that we make as programmers - asserting the policy check before the processing of the request - is counterintuitive from a user perspective. The preferred behavior is to say "if supplying the argument results in the same end condition as not supplying any argument (because the argument supplied is the default anyway) then allow it". Proposed change ----------------------- The proposed change I submitted to neutron is to bypass oslo.policy checks for method arguments when all boolean method arguments equal the configured default. If any boolean arguments differ from the default, or if there are any other arguments specified that are controlled by policy, then execute the oslo.policy checks as normal. Here are a few examples: - Regular project user creates a network specifying shared=false. - Current behavior: regular user cannot specify the shared attribute, denied. - Proposed behavior: "shared=false" is the default when creating networks, so allow it. - Regular project user creates a router specifying that it be non-HA. - Current behavior: regular user cannot specify the "ha" attribute, denied. - Proposed behavior: "ha=false" is the default when creating routers, so allow it. In neutron the oslo.policy check is done in the API base [2] almost immediately upon receipt of an API request, not as a decorator in the keystone style. So comparison of supplied boolean attributes against defaults could be done at that point centrally. The Concern ----------------------- The concern raised - and what I hope to get the API SIG's guidance on - is whether this raises any kind of security concern. I don't think it will. Since we are comparing equivalence of the user supplied attribute to the default, the end result of a request permitted by this proposal should always be the same as a request where the user did not supply that argument. But your wisdom would be appreciated in validating that assumption. Thanks for your feedback, Nate [1] https://bugs.launchpad.net/neutron/+bug/1821208 [2] https://opendev.org/openstack/neutron/src/branch/master/neutron/api/v2/base....