Re: [xacml] Behavior of deny-overrides

[Seth Proctor <Seth.Proctor@sun.com>]

Hi Erik. Formalisms aside, I think the basic issue you're reacting to is
that the rule and policy versions of deny-overrides work differenly (and
yes, this is well-known). It's certainly possible that this could add
confusion to policy analysis, though in practice I've never seen it
happen. Personally, I don't see any problem with the current behavior.
There is certainly nothing incorrect about it, although it may well be
unexpected.

A few comments..

> P1 has a singe rule with a Permit effect. This policy in isolation can
> never evaluate to a Deny.

That's not actually true. Using only the standard 2.0 combining
algorithms, it can never result in Deny. Since I am free to write my own
combining algorithm, however, the policy certainly can return Deny.

> [...]
> So, why is this a problem? Because it makes harder to understand a
> complex policy. You cannot look at the parts in isolation. For instance,
> if several administrators are responsible for parts of a large policy
> set, then their policies could have effects that they did not intend or
> anticipate.

I'm not sure that I agree here. As the author of P1, I shouldn't need to
know what's above me. All I care is what my Rules return. Likewise, as
the consumer of P1, I know that I'm using a specific algorithm that may
or may not re-interpret the results of my children. If I am both
parties, then I have a global view. It's true that I can't look at just
a leaf node in isolation to understand why some decision was made, but
then that is always the case.

> One could argue that the algorithms have a well defined behavior, so
> they are not “wrong” and they behave as intended. That could be said
> about the only-one-applicable algorithm for instance, or if I for some
> reason want to define an algorithm which inverts everything, makes its
> decisions randomly, or whatever.
> 
> However, in the case of deny-overrides, the algorithm could have been
> designed so it would have been sound in this respect.

Again, I don't think it's an issue of soundness. The question is whether
you expect the policy and rule variants of a given algorithm to always
behave in the same manner. Maybe this would have been the place to start
(see below), but I think most people today understand the current
behavior.

> Olav suspects (and so do I) that the motivation for the current design
> was based on concerns about access being allowed in case of an error: If
> PS uses deny-overrides and P1 evaluates to indeterminate, then perhaps
> P1 could have evaluated to Deny if there was no error? So to be safe, we
> make the whole a Deny. However, it would have been better to make it
> indeterminate, and then have a Deny biased PEP instead, if denying
> access is important in case of uncertainty in policy evaluation.
> 
> Is this already known? Is it a concern? To fix it, we could define a new
> combining algorithm which does not have this behavior and recommend
> people to use it instead of the old one.

My advice would be against adding new algorithms or changing the
existing ones. Already I get regular questions about why there are
ordered and un-ordered algorithms, something that was added to help with
the formal logic of the system. In practice, I've never seen anyone get
tripped up by the current behavior, and anyone who is truly worried
about debugging their policies for this case can always use a custom
algorithm that behaves differently. Just my opinion..


seth