Re: ldapACI permissions

[Kyungae_Lim@iris.com]

                    George_Robert_Blakley_III@                                                              
                    tivoli.com                        To:     Kyungae_Lim@iris.com                          
                                                      cc:     ietf-ldapext@netscape.com, djbyrne@us.ibm.com 
                    03/22/00 12:10 PM                 Subject:     Re: ldapACI permissions                  
                                                                                                            
                                                                                                            









All,

> < djb > I agree with your analysis that having both delete and add
> permission on the object essentially means that one could delete the
> object, and re-add it, filling in attributes, and access control as it
> liked.    If the concern is that users would circumvent the access
control
> checks by doing this sort of thing, I might suggest that an auditing
> facility is needed for that directory.

> Is the suggestion here that  when creating an entry, a user can only set
> the values on those attributes to which he also has 'write' permission?
> Does this also mean the user needs 'write/delete' permission on all
> attributes which have values when he is deleting the entry?

I think both 'add' on entry and 'write' on attributes SHOULD be checked
when creating an entry.  Otherwise there is no way to prevent a user with
'add' permission only from filling in ldapACI or other security-sensitive
attribute values.
Auditing can help detecting the problem( after the fact), but shouldn't be
a substitue for access checking.


<bb> Note that implementations can use the "Policy Owner" attribute to
insure
that ldapACI attributes
<bb> can't be changed by anyone other than security administrators -
including
at object creation time.
<bb>
<bb> Given that there is this level of control (assuming an appropriate
implementation), it should be
<bb> possible to insure that the system configures a new entry's default
Access
Control policy to
<bb> ensure what you want without having to force all implementations to do
this
in a particular way.

If I understand the draft correctly, it does not mandate how the "Policy
Owner" attribute should be implemented.  I suppose in some implementations
the "Policy Owner" can be expressed as another ACI - write access to the
ldapACI attribute, on the basis that if you have write access to ldapACI,
you essentially have full access to that object.  In such implementation
the "Policy Owner" checking is equivalent to write access checking on the
attribute.

<bb>
<bb> What we're really talking about here is the default policy which
applies to
a newly created
<bb> object.
It is not just ldapACI - the question is, should a user with the 'add'
permission be allowed to set ANY attribute value during object creation
time, or is there a way for the administrator to restrict access to enter
certain (sensitive) attributes while still granting the 'add' permission?
<bb>
<bb> Our choices here seem to be:
<bb>
<bb> (1) Allow the creator of the object to set values for specified
attributes
(including ldapACI) based
<bb>       on permissions governed by an ACL inherited from an ancestor
entry.
<bb> (2) Allow the creator of the object to set values for all attributes
EXCEPT
ldapACI attributes
<bb>       -- only the policy owner can change the ldapACI attributes
<bb> (3) Allow the creator of the object to set values for ALL attributes -
in
this case control over the
<bb>       ldapACI for the newly created object is governed by the ACL on
the
containing directory.
<bb>
<bb> Can we get some discussion toward a consensus here?

How is 3) different from 1)?


--bob

Bob Blakley
Chief Scientist
Tivoli SecureWay Business Unit