[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Combining algorithm combining orders
All, In my opinion the both the deny overrides and permit overrides policy combining algorithms are wrong. They treat errors in an incorrect and unsecure manner. The corresponding rule combining algorithms are correct, and the policy combining algorithms should work in a similar manner. The Indeterminate result in XACML is used in those places where the result of some part of the policy cannot be determined because of some form of error. It is important that if such an indeterminate result affects the final decision of the PDP, that the indeterminate is returned to the PEP so that the PEP knows that there is an error. If so is not done, errors in policies might not be noticed or an attacker might be able to force the PEP into some bad action by causing errors in the PDP (for instance by interrupting attribute provisioning services). If we want to determine whether an Indeterminate should affect a result, we can consider the indeterminate to be a result which potentially could be either Permit, Deny or NotApplicable and for each of them see what the overall result would be. If the overall result depends on which choice we make for the Indeterminate, then the Indeterminate should be propagated "further up" in the policy evaluation. (If you don't understand what I mean, just read on, I will provide examples.) Currently the permit overrides policy combining algorithm works like this (using the updated textual description): 1. If any policy evaluates to "Permit", the result is "Permit". 2. Otherwise, if any policy evaluates to "Deny", the result is "Deny". 3. Otherwise, if any policy evaluates to "Indeterminate", the result is "Indeterminate". 4. Otherwise, the result is "NotApplicable". Notice how a deny goes before indeterminate. That is a bad priority. Consider a policy set with two policies A and B. Assume that A is deny and B is indeterminate. Consider what the overall result could be if policy B would not have an error in it: A: Deny B: could be Deny -> overall would be Deny A: Deny B: could be NotApplicable -> overall would be Deny A: Deny B: could be Permit -> overall would be Permit Notice how the result depends on what the indeterminate could potentially be. However the current definition gives a definite Deny in all cases. This breaks the error propagation safety of the combining algorithm. In some applications availability could be critical, and a PEP might have a bias that indeterminate means that access is allowed. In such a case harm could be caused by this behavior. Now consider the deny overrides instead. Currently the deny overrides policy combining algorithm works like this (using the updated textual description): 1. If any policy evaluates to "Deny", the result is "Deny". 2. Otherwise, if any policy evaluates to "Indeterminate", the result is "Deny". 3. Otherwise, if any policy evaluates to "Permit", the result is "Permit". 4. Otherwise, the result is "NotApplicable". Note how an indeterminate is converted to a Deny. This gives the following behavior. A: Permit B: could be Deny -> overall would be Deny A: Permit B: could be NotApplicable -> overall would be Permit A: Permit B: could be Permit -> overall would be Permit Again, there is a definite result from the combining algorithm although the underlaying logic is ambiguous. As I said we have discussed this previously. The threads are here: http://lists.oasis-open.org/archives/xacml/200701/msg00020.html http://lists.oasis-open.org/archives/xacml/200702/msg00019.html I propose that we define new identifiers for new combining algorithms for 3.0 which work like this: Deny overrides: 1. If any policy evaluates to "Deny", the result is "Deny". 2. Otherwise, if any policy evaluates to "Indeterminate", the result is "Indeterminate". 3. Otherwise, if any policy evaluates to "Permit", the result is "Permit". 4. Otherwise, the result is "NotApplicable". Permit overrides: 1. If any policy evaluates to "Permit", the result is "Permit". 2. Otherwise, if any policy evaluates to "Indeterminate", the result is "Indeterminate". 3. Otherwise, if any policy evaluates to "Deny", the result is "Deny". 4. Otherwise, the result is "NotApplicable". Best regards, Erik
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]