OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [xacml] New issue#1 from "Boolean Policy resolution"


 > JMaclean@affinitex.com wrote:

> While I understand that you are proposing that "n/a" is effectively 
> ignored, I can't agree with it.
> 
> The question being asked is should access be granted. In this case, the 
> policy administrator has written a rule that implies that both 
> predicates must allow access before the requester is granted access; 
> however, policy administrator has referenced policy that does not apply. 
> In security and access control system, it is better to error on the side 
> of caution and not grant access if there is any uncertainty.
> 
> 
> t AND n/a = n/a
> t AND n/a = f


this is precisely my point.



 > Polar Humenn wrote:

 > Well, it doesn't matter what you call it. However, if you are going to go
 > with standard logic practices, then OR would have to change 
accordingly as
 > well, esspecially if you have NOT, and you want to preserve things like
 > Demorgan's Law. All of which exists for a reason, perhaps forgotten by
 > many long ago.

i am not trying to argue the logic, but the ramifications. this is why i 
proposed the term JOIN. yes, it is just a syntatic change, but JOIN 
doesn't carry the evaluative weight of AND in my mind. heck, we can call 
it FRED for all i care, just so long as AND requires all predicates to 
evaluate to true (or the term is done away with for that matter)

 > If there is a problem with semantics, we certainly can change the names.
 > However, we introduced N/A in the logic for a specific purpose, and hence
 > felt it necessary to go with a three valued (4 with Error) logic for
 > policy composition purposes. The semantics we want for a policy that
 > doesn't apply means that it doesn't enter into the equation. It doesn't
 > evaluate to true. It is a "I Don't Care".

...and what i am saying is that "i don't care" ain't going to cut it for 
a security descriptor leading to a GRANT.

 > The <N-OF n=3>pred1 pred2 pred3</N-OF> construct gets you what you 
want by
 > requiring all predicates to return TRUE.  We could certainly add an
 > equivalent operator of <ALL-OF> for the proper semantic meaning.
 > But then again, I don't see a lot of Humans writing security policy in
 > XML, so the sugar should be unnecessary. If I'm wrong, I'll go back to
 > playing with my Turing machine. :^)

i think that the N-OF solution is workable, but what i am concerned 
about is the implications of an AND. no, most policy won't be written by 
humans, but the software that generates it is and unless we make some 
sort of HUGE distinction about the use of AND, i fear that it will cause 
issues.

b





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC