The Indeterminate flavors question

[Erik Rissanen <erik@axiomatics.com>]

All,

Here are some examples which illustrate the points I was trying to make 
during the TC meeting last week.

The first example intends to show why it is necessary to evaluate the 
children in order to determine the flavor of Indeterminate from a target.

Consider the following policy:

Policy:
    target: resource-id = printer
            subject-id = alice
    Rule[Effect=Permit]

Assume we have the following request:

Subject:
   subject-id = alice
Resource:
   resource-id = printer

For this request this policy would say Permit.

Now consider this policy:

Policy:
    target: resource-id = bank-account
            subject-risk-level = HIGH
    Rule[Effect=Deny]

This policy would say NotApplicable for the same request as above.

Now, assume that we collect the two policies in a policy set:

PolicySet
   Target: subject-location[MustBePresent='true'] = office
   Policy:
      target: resource-id = printer
              subject-id = alice
      Rule[Effect=Permit]
   Policy:
      target: resource-id = bank-account
              subject-risk-level = HIGH
      Rule[Effect=Deny]

Now, let's evaluate this policy against the example request from above.

The target of the policy set will be Indeterminate because the 
subject-location attribute is missing. Now, which flavor of 
Indeterminate should it be? It should be Indeterminate{P} since only a 
permit could have been produced if the target would not have failed. And 
we know that only if we evaluate the children. Note that simply scanning 
the policy tree for effects would incorrectly conclude that the policy 
might have evaluated to a Deny for this request.


Now, there was another issue which was discussed at the meeting, namely 
that Paul had an idea that instead of having to actually evaluate all 
the children, one could think of the policy is being transformed. I need 
to bring up another example to illustrate that. (I did not want to mix 
two issues in the same example policy.)

Consider this policy set:

PolicySet
   Target: subject-location[MustBePresent='true'] = office
   Policy[CombAlg='deny-unless-permit']:
      Target[empty]
      Rule[Effect=Permit]
        target: resource-id = printer
                subject-id = alice
      Rule[Effect=Deny]
         target: resource-id = bank-account
                 subject-risk-level = HIGH


Again, let's evaluate the policy set with the example request from 
above. The policy set target is indeterminate, so the policy set is 
Indeterminate as a whole. If we would evaluate the children to determine 
the flavor of Indeterminate, we would get Indeterminate{P}, like above 
because the rule about bank accounts does not apply.

Now, Paul thought one could rewrite this policy set by adding the 
expression from the policy set target in each leaf rule as a condition. 
However, I pointed out that it won't give the same result because of the 
combining algorithms. In this case, the rewritten policy would be:

PolicySet
   Target[empty]
   Policy[CombAlg='deny-unless-permit']:
      Target[empty]
      Rule[Effect=Permit]
        target: resource-id = printer
                subject-id = alice
        condition: subject-location[MustBePresent='true'] = office
      Rule[Effect=Deny]
        target: resource-id = bank-account
                 subject-risk-level = HIGH
        condition: subject-location[MustBePresent='true'] = office

Íf we evaluate this policy set against the example request, we get 
Indeterminate in both rules because of the missing attribute in their 
conditions. However, the 'deny-unless-permit' algorithm is going to 
change that to a Deny for the policy which contains the rules, so 
overall we get Deny, which is different from the policy set before we 
transformed.

The question Paul brought up during the meeting was whether this was 
intended. Clearly that is what the spec says happens since the 
evaluation tables allow a combining algorithm to make a decision among 
several conflicting decisions. I guess what Paul is thinking about is 
that there should be some kind of "linearity" requirement, by which 
certain properties of the policy are immutable under certain types of 
transformations in the policy.

However, there are currently no general requirements on the algorithms 
which would guarantee that certain decisions are not overridden. I don't 
think there should be either.

Best regards,
Erik