Hi All,
In order to minimize any disruption this suggestion might cause
(assuming that people even agree with the logic as I am still open to
the possibility that I have missed some essential point), I believe
there is a fairly simple way to address it for 2.0 and we can consider
if it makes sense to combine Policy and Rule in 3.0 after that is
resolved. First, I will present a recommendation for consideration,
then follow it with an attempt at a little more clarity as to what the
problem being addressed is.
Assuming that people are familiar with the p-code combining algorithm
logic in Appendix C in combination with the rule, policy, and policyset
value determinations in Chapter 7 (7.9, 7.10, 7.11) the following
should be understandable in that context.
Let us start by defining 4 variables (refs are to XACML 2.0 spec):
- ruleValue(i) = evaluate(rule(i)) // i(1->n); eg line 5156,
C.1, p 132,, and sec 7.9 Table 4
- ruleEffect(i) = effect(rule(i)) // = 01-binary for Permit,
10-binary for Deny
- policyValue(j) = evaluate(policy(j)) // j(1->m); eg line
5211, C.1, p 133
- policyEffect(j) = and(effect(rule(1->n)) // result = 01 all
Permit, 10 all Deny, 00 mix of Permit/Deny
Given those variables, assume for the moment that we can leave the
rule-combining algorithm alone (lines 5149-5194),
the policy combining algorithm could be modified as follows:
- the block of logic following line 5225 (if (decision = =
Indeterminate) ) would now have to take into account the fact that the
policy might be only capable of making one type of decision, which
would be determined by the value of policyEffect
- policyEffect can easily be calculated when the policy is
evaluated at the top of the loop by "and"ing the effect of each rule as
the rules get evaluated (e.g. insert something "policyEffect =
policyEffect & effect(rule[i])" after line 5156 in rule-combining
algorithm)
- now, similar to the rule combining algorithm we could use the
same logic as the rule-combining algorithm to determine the result of
policy combining
The reason the above should work is that the meaning of "Effect" should
be thought of as indicating that the contents of the element can
produce either: only a Permit (01), only a Deny (10) or a mix of Permit
and Deny (00).
Given the above logic one can readily see that if we take the strict
administrative view that if a potential Deny in a Deny overrides should
be a Deny, then line 5183 should be return Deny as indicated in first
email. If we took a lax administrative view 5183 could return
Indeterminate, which effectively introduces the ambiguity previously
discussed, which is probably undesirable, but could be included by
defining a lax-deny-overrides combing algorithm. i.e. section C.1
actually defines a lax-deny-overrides rule combining algorithm (because
line 5183 renders the result ambiguous, unable to determine whether any
of the contained rules actually were a potentialDeny).
If we now re-visit Erik's original use case:
Let's assume policy P1 is (lax-)deny-overrides since it is
within a deny-overrides policy PS. As Erik indicated, P1 returns
Indeterminate based on existing lax rule-combining, and PS returns Deny
based on existing policy combining.
With the above suggestion the first change we would have to apply is
that PS would now include the Effect of P1. As shown above the Effect
of P1 would be Permit since it only contains one Rule and that Rule has
an Effect of Permit. Now, when P1 was evaluated under PS, instead of
the existing policy combining we would be using the logic of the
existing rule-combining and substituting the policyEffect in line 5174.
Since the policyEffect is Permit, we would not raise the potentialDeny
condition and the result would be Indeterminate, which would correct
the problem that exists using current methods.
I believe this relatively simple change would solve the problems that
currently exist, with little or no impact on XACML 2.0 except to say
that we would recommend using these combining algorithms that include
the policyEffect as part of the logic.
However, for 3.0, I think we will probably find that the net effect of
this is that the logic of the rule-combining and policy-combining
algorithms become equivalent, which removes the need to have 3 separate
concepts of PolicySet, Policy, and Rule. At the simplest level a Policy
effectively becomes a PolicySet with a rule-combining algorithm, and
PolicySets now effectively can contain an implicit "Effect" if all
their child Rules and PolicySets have "Effect"s that produce a single
result of Permit or Deny.
Comments and suggestions welcome.
Thanks,
Rich
Rich.Levinson wrote:
4904297B.4040601@oracle.com" type="cite">Hi All,
While there are probably some details in the previous email that need
to be cleaned up, I think that it identifies a basic problem that needs
to be addressed.
As indicated, Erik came up with a single rule policy where the rule had
an effect of permit, and yet the policy that wrapped it effectively
produced a deny at a higher level.
I believe the root cause of this problem is that the concept of
"Effect", and its implementation in the current XACML specs is
fundamentally flawed and needs to be addressed.
Again, with Erik's use case, the flaw is obvious: a Rule with an Effect
of Permit results in a Policy that causes a Deny. The flaw is that the
concept of Effect is not handled properly. "Effect" effectively means
that the block of logic contained within this element can ONLY produce
either a Deny or a Permit, but not both. On the other hand, because a
Policy does not have an Effect, it implicitly can produce either a Deny
or a Permit. Therefore, to preserve the notion of "Effect", we have to
include it also at the Policy level, with the following constraints:
The Effect of a Policy must equal the "AND" of the Effects of all of
its Rules. Therefore if a Policy has only Rules that are Permits, then
the Effect of the Policy is Permit. If the Policy has Rules with both a
Permit and Deny, then the Policy effectively has no "Effect" because
the meaning of "Effect" is that only one type of decision is possible,
and now the Policy can produce two types of decisions.
Therefore, I think my basic conclusions in prev email are correct about
converging Policy and Rule into a single element - i.e. the only thing
that distinguishes the Rule and single Rule Policy is the fact that the
Rule has an Effect and the Policy doesn't, which has been shown above
to be wrong and correctable by giving the Policy an Effect attribute,
which effectively removes the distinction between Policy and Rule.
Comments and suggestions will be much appreciated.
Thanks,
Rich
Rich.Levinson wrote:
Hi Erik and TC,
As indicated at today's meeting, I have concerns about the proposed
changes. I have read this email from Erik fairly carefully, as well as
the first part of the cited reference:
http://lists.oasis-open.org/archives/xacml/200701/msg00020.html
and I also started to follow the thread initiated by Daniel:
http://lists.oasis-open.org/archives/xacml/200810/msg00027.html
In the first cited reference, Erik states:
"P1 has a singe rule with a Permit effect."
then goes on about how this Rule gets propagated up and effectively
turns into a Deny under the deny-overrides algorithm.
I agree that this appears incorrect, and went to look for the source of
that problem.What I found was that it appears this problem results from
what appears to me to be an error in the deny-overrides *rule
*combining algorithm, which has what I believe is an incorrect piece of
logic on lines 5181-5184 of the XACML 2.0 core spec, p 133:
5181 if (potentialDeny)
5182 {
5183 return Indeterminate;
5184 }
It is my opinion the line 5183 should say "return Deny", because it is
at this point that the "potentialDeny" condition that the algorithm
goes to the trouble to find, now throws away, which ends up creating
the situation where a rule with effect = Permit can produce a Deny at
the policy combining level.
I also read Daniel's comment up to the point where he said:
"Just throwing an exception all the way to the client is what we
have tried to avoid.",
with which I agree. I expect that many policy administrators will want
definitive results to come out of the PDP, and not any
"Indeterminates".
So, my first suggestion would be to fix what I consider to be an error
on line 5183 described above. The practical reason why I consider this
an error is that if there is insufficient information to evaluate a
rule that has an effect = Deny, then, I believe it is legitimate to
define a rule combining algorithm that says that rule should return the
effect = Deny so that one cannot remove input attributes in the hopes
of reversing a decision. One could also define a companion combining
algorithm the evaluated to Indeterminate in order to provide that
option for those who want it. This way a policy administrator could
choose on a case by case basis which behavior is preferable based on
specific situations.
My second suggestion is more broad-based, and, in fact, I think we
should consider for 3.0 if there is some agreement. I am not expecting
what follows to be bought hook line and sinker at first glance, but I
do think it is worth consideration, especially since we are already
making a major paradigm shift with the category-based attributes that
are defined in 3.0, that effectively adds a new "dimension" to the
domain of attributes, which I believe is a desirable step forward from
the Subject,Resource,Action,Environment-based attributes of 2.0, which
based on previous discussions about the what appear to me as ambiguous
and unnecessary semantic restrictions on the Action attribute
"category". Personally, I would recommend in section B.6 of 3.0 that
the action attributes be defined within a given "resource" category, as
I believe that actions are attributes of resources and do not have any
meaningful definition outside of a resource context. However, that is
just a minor aspect of the overall suggestion I have related to the
combining algorithms.
The main suggestion about combining-algorithms is that I believe, but
have not definitively proven yet, that there is an unnecessary layer of
combining with two types of rule and policy combining that exists in
2.0. One easy way to see that this might be true is to do the following
thought experiment:
1. Wrap every "Rule" within a Policy element, which effectively turns
every policy into a single rule policy. However, if we do this,
then we lose the "Effect" behavior of the Rule, therefore
2. Move the Effect attribute up to the Policy level. Therefore, each
single Rule Policy now also preserves the Effect.
3. Clearly all multi-rule Policies must now become PolicySets, and
the policy-combining algorithm must be replaced by the logic of
the rule combining algorithm to take into account the Effect of
the Policies.
4. We are now left with a collection of single rule Policies (with an
effect) and PolicySets that have no effect since it was factored
out in step 3. This is where it gets "fuzzy", but I suspect that
we might be able to show that we can still use the rule combining
algorithms on a mix of entities some of which have an effect and
some which don't. I suspect that for example on lines 5174-5177
that we can just skip this block if the entity being tested is a
PolicySet, and execute it if the entity is a Policy. If so, then I
think we are done and have factored the distinction between
rule-combining and policy-combining out of the structure.
If the above logic is correct, and we can reduce the structure to be
simply Policies with an effect and PolicySets with no effect, and allow
the combining algorithms to only use the "effect" segments on the
objects that contain an effect, then I think we reduce the complexity
of the syntax (either no longer have "Rule"s or no longer have
"Policy"s) at the cost of only what appears to me to be a tiny increase
in the complexity of the rule-combining syntax (which is to effectively
allow for rules that have no effect and simply bypass the effect
logic).
Bottom line is that I am offering this as a potential suggestion.
Because the logic to analyze it is fairly complex, I allow for the fact
that maybe I have missed something essential. However, since we are
making some fairly broad changes in 3.0, I am offering this as a
potential "simplification". At the very least, I am looking to find
what I might be missing that would prevent this "simplification".
Thanks,
Rich
Erik Rissanen wrote:
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
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|