Subject: Examples (differing privileges, DNs) for aci-model-04

From: "Brian Jarvis" <[email-masked]>
Date: Thu, 21 Oct 1999 16:40:24 -0600

I would like to clarify my understanding of how ACIs interact with each other by giving examples and what I expect the resultant rights to be.  In most cases, I have been unable to decide from aci-model-04 what the results should be.  I propose expanding the example section with any of these that are deemed useful by the collective.

Please excuse my abbreviated LDIF format:
1.  I've only included the ACI attributes.
2.  I've also numbered the ACIs for ease of discussions and explanations.
3.  I've only given the RDN instead of full DNs on the aci.
     cn=bjarvis, ou=ABC, o=XYZ, c=US
     cn=G1wBJarvis, ou=ABC, o=XYZ, c=US
     cn=G2wBJarvis, ou=ABC, o=XYZ, c=US

For all of these
assume cn=bjarvis is a member of group cn=G1wBJarvis
assume cn=bjarvis is a member of group cn=G2wBJarvis

Example #1
dn: o=XYZ, c=US
aci#1.1: 1.2.3.4#subtree#grant;r;attribute1;#access-id#cn=bjarvis
aci#1.2: 1.2.3.4#subtree#grant;w;attribute1;#group#cn=G1wBJarvis

What rights does cn=bjarvis have to attribute1 of o=XYZ, c=US?
Two reasonable answers:
A1.1: r    (aci#1.1 overrides aci#1.2 because access-id is higher precedence than group)
A1.2: r,w    (rights are ORed between aci#1.1 and aci#1.2)
I can see how some might prefer A1.1, but I strongly prefer A1.2.
I submit that "because access-id is higher precedence than group" does not apply because both ACIs are grants.

Example #2
dn: o=XYZ, c=US
aci#2.1: 1.2.3.4#subtree#grant;r;attribute2;#group#cn=G1wBJarvis
aci#2.2: 1.2.3.4#subtree#grant;w;attribute2;#group#cn=G2wBJarvis
 
What rights does cn=bjarvis have to attribute2 of o=XYZ, c=US?
One reasonable answer:
A2.1: r    (rights are aci#2.1 "OR" aci#2.2)
I strongly prefer A2.1.

Example #3
dn: o=XYZ, c=US
aci#3.1: 1.2.3.4#subtree#grant;r,w;attribute3;#group#cn=G1wBJarvis
aci#3.2: 1.2.3.4#subtree#deny;w;attribute3;#group#cn=G2wBJarvis
 
What rights does cn=bjarvis have to attribute3 of o=XYZ, c=US?
Two reasonable answers:
A3.1: r    (rights are aci#3.1 "minus" aci#3.2)
A3.2:none    (aci#3.1 overrides aci#3.2 because deny is higher precedence than grant)
I strongly prefer A3.1.

Example #4
dn: o=XYZ, c=US
aci#4.1: 1.2.3.4#subtree#grant;w;attribute4;#access-id#cn=bjarvis
aci#4.2: 1.2.3.4#subtree#;r;attribute4;#access-id#cn=ABC
 
What rights does cn=bjarvis have to attribute4 of o=XYZ, c=US?
Two reasonable answers:
A4.1: w    (aci#24.2 has no bearing--no "identity equivalence")
A4.2: r,w    (rights are aci#1.1 "OR" aci#1.2 because of "identity equivalence")
I can see how some might prefer A4.1, but I strongly prefer A4.2.

Four examples ought to make a good start.

--the walrus
a.k.a. Brian Jarvis
[email-masked]

---

From: "Bob Blakley" <[email-masked]>
Date: Fri, 22 Oct 1999 15:44:33 -0500

David Chadwick wrote:

>Brian
>Here are my preferred options (which I believe are also compatible
>with the X.500 ACDF)

I want to observe before starting into the details that we were trying to
AVOID
constraining the policy semantics of back-end implementations in the draft
because several LDAP implementors had made incompatible choices, and
specifying semantics at this level might require them to change established
implementation behaviors.  However, if the group feels strongly that it's
appropriate
to do this, I'm happy to see it happen ("the more standard, the better"), and
my preferences are enumerated below.

>> A1.2: r,w    (rights are ORed between aci#1.1
>> and aci#1.2) I can see how some might prefer A1.1, but I strongly
>> prefer A1.2. I submit that "because access-id is higher precedence
>> than group" does not apply because both ACIs are grants.
>
>A1.2 would be my choice.

My choice is A 1.1, for two reasons:

(1) This choice is the one implemented by UNIX, NT, DCE, and a host of other
access control systems.  The practical import of this is that security
administrators
are accustomed to the strict precedence model, and if you give them something
different they'll be confused based on their experience of many other systems.

(2) Implementing A 1.2 is substantially more complicated than implementing A
1.1.
With a strict-precedence model (A 1.1), the implementation can check for which
entries
are eligible to participate in the decision using the precedence rules, then
execute a very simple combination algorithm (e.g. AND, OR, or either of these
with a slight modification to implement the precedence of deny vs. grant).
With the hybrid model proposed in A 1.2, you have to consider ALL entries in
every access decision, and examine every entry to see whether the particular
operations requested are granted or denied.  You also have to worry about
whether
entries which don't mention the requested operation should be treated as
"default grant" or "default deny", and you have to run a hierarchical decision
algorithm over all entries if you encounter any entry which has either an
explicit
or an implicit deny for any one of the requested operations.  The code is much
more complicated, and because in the normal case (i.e. granted access) it must
look at the permissions for all entries in the ACL, it is also slower.

I feel very strongly about this one.

>I would strongly prefer r and w which is not in your list (although I
>suspect there is an error in your email, since you only gave one
>option)

Like David, I strongly suspect that Brian's A2.1 is supposed to be
"rw", not "r", and this is the option I prefer.  But I feel compelled to
observe that there is another reasonable answer:

A2.2: no access (rights are aci#2.1 "AND" aci#2.2)

>> A3.2:none    (aci#3.1 overrides aci#3.2 because deny is higher
>> precedence than grant) I strongly prefer A3.1.
>>
>
>Agreed.

I agree also, but you have to consider another case also -- what happens if
the
order of aci#3.1 and aci#3.2 are reversed?  Is evaluation of these policies
order-sensitive?  If so, then evaluating the two commands in reverse order
results in "rw".  If we don't support order-sensitivity, then there's no way
(administratively)
to reverse the effect of a "deny" operation without actually deleting the ACL
entry
and creating another entry with the same DN (which seems clumsy).

>A grant should not override a grant.

But I don't understand what's meant by this statement.

>> A4.2: r,w    (rights are aci#1.1 "OR" aci#1.2 because of "identity
>> equivalence") I can see how some might prefer A4.1, but I strongly
>> prefer A4.2.
>
>I dont follow where your identity equivalence came from. Sorry.
>Was ABC meant to be an alias of bjarvis?

I'm with David here.  "Huh??"

--bob

Bob Blakley ([email-masked])
Chief Scientist, Dascom

---

From: "Brian Jarvis" <[email-masked]>
Date: Tue, 26 Oct 1999 12:36:30 -0600

>suspect there is an error in your email, since you only gave one 

I agree with you.  This was a typo.  It should have been (only added ",w"):

Example #2
dn: o=XYZ, c=US

What rights does cn=bjarvis have to attribute2 of o=XYZ, c=US?
One reasonable answer:
A2.1: r,w    (rights are aci#2.1 "OR" aci#2.2)
I strongly prefer A2.1.

--the walrus
a.k.a. Brian Jarvis
[email-masked]

---

From: "Brian Jarvis" <[email-masked]>
Date: Tue, 26 Oct 1999 14:13:38 -0600

>Was ABC meant to be an alias of bjarvis?

Obviously I did not explain well enough.  My appologies.  ABC is the parent of bjarvis.

>Please excuse my abbreviated LDIF format:

...
>     cn=bjarvis, ou=ABC, o=XYZ, c=US

Here is Example 4 again, in a form that should be clearer.

Example #4
dn: o=XYZ, c=US
aci#4.1: 1.2.3.4#subtree#grant;w;attribute4;#access-id#cn=bjarvis, ou=ABC
aci#4.2: 1.2.3.4#subtree#;r;attribute4;#access-id#ou=ABC

in aci#4.2, you can replace "access-id" with "subtree" or assume that access-id has been extended to include the subtree.

What rights does cn=bjarvis have to attribute4 of o=XYZ, c=US?
Two reasonable answers:
A4.1: w    (aci#4.2 has no bearing--rights on an object override those given to an ancestor)
A4.2: r,w    (rights are aci#1.1 "OR" aci#1.2--rights on an object = direct rights + rights given to ancestors)
I can see how some might prefer A4.1, but I strongly prefer A4.2.

--the walrus
a.k.a. Brian Jarvis
[email-masked]

---

From: "David Chadwick" <[email-masked]>
Date: Wed, 27 Oct 1999 22:32:17 +0100

> aci#4.1: 1.2.3.4#subtree#grant;w;attribute4;#access-id#cn=bjarvis,
> ou=ABC aci#4.2: 1.2.3.4#subtree#;r;attribute4;#access-id#ou=ABC
> 
> in aci#4.2, you can replace "access-id" with "subtree" or assume that
> access-id has been extended to include the subtree.
> 
> A4.1: w    (aci#4.2 has no bearing--rights on an object override those
> given to an ancestor) A4.2: r,w    (rights are aci#1.1 "OR"
> aci#1.2--rights on an object = direct rights + rights given to
> ancestors) I can see how some might prefer A4.1, but I strongly prefer
> A4.2.

I agree with. r, w seems best to me. Jarvis gains r because he is a 
member of the ABC group
David

> [email-masked]

***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email [email-masked]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************