Re: ldapACI permissions

[Ryan Moats <jayhawk@att.com>]

We made a number of comments on this section that are driven by two
different concerns.

First, there are several cases where two or more permissions will apply
to a single LDAP operation and the precedence of those permissions is
not clear in the text.  The particular example in this email deals with
the interaction of the "a/d" permissions for entries and the "w"
permission for attributes; some of our other comments dealt with other
interactions.

We feel the document needs to go through these cases and explain how
potential permission conflicts are resolved.  In this particular case,
the intent seems to be that "d" permission at the entry level allows
deletion of all attributes in the entry even if "w" permission is
denied for some or all of those attributes, and that "a" permission for
entries allows any attribute in the created entry to be given values
even if "w" permission is denied for some or all attributes.  This
should be stated in the text.

The second concern is that we are nervous about the consequences of
allowing "a" permission to provide values for attributes where the
subject may not have "w" permission for some attributes.  Surprises
should always be avoided in security, and here we have a case where an
explicit denial of permission can be overridden by granting a different
permission.  We also agree with the previous comment on the list that
auditing only helps after the fact (or were you suggesting an audit
tool that looks for conflicts between "a/d" permissions on entries and
"w" permissions on the attributes of those entries?).

On the other hand, we recognize the validity of your argument about
object creation in the last paragraph of your message below.  To date,
we have been unable to come up with a real-world example where a
subject with "a/d" entry permissions would not also need/have "w"
permissions on the objects created.  Given that fact, we can live with
our nervousness and accept the behavior as long as it is described in
the document.

Rick Huber
Ryan Moats

: From: djbyrne@us.ibm.com
: To: rvh@qsun.mt.att.com (Richard V Huber)
: cc: blakley@dascom.com, stokes@austin.ibm.com, ietf-ldapext@netscape.com
: Subject: Re: ldapACI permissions

My Comments preceded by < djb >


Thanks,

Debora Byrne
Manager Secure Way Directory Config / User Interface
INet: djbyrne@us.ibm.com
Phone: (512)838-1930 ( T/L 678 )


: >TECHNICAL: What's the interaction between "[entry]" and attributes: if
: >somebody has add permission for objects but is denied permissions for
: >certain attributes, what happens?
:
: (EJS) None.  [entry] applies to the permissions a/d/e/b.  [all] applies
to the
: permissions for attributes.  If a person has add permission, then he can
add
: an entry and its attributes to that place in the DIT.  The permissions
for the
: attributes he added as part of adding that entry are governed by the
access
: control attribute (ldapACI) that is added to that entry.

So inherited access rights on attributes don't apply when a new object
is being created; the only thing that applies is the permission to
create a new entry.  A person can write all attributes of a newly
created object even if inherited attribute rights say the person canNOT
write some of those attributes.  But as soon as the entry has been
created, the creating entity can not change any attribute unless
inherited rights permit it.  Also, the creating entity CAN create a new
ldapACI attribute as part of the new entry and thus override any
inherited rights.

Taken together, this means that entry level a/d rights mean you can
change anything in an entry since you can always delete, then re-add
with whatever attribute values you want.  This makes us nervous.

< 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?

While the draft maintains that the inheritance model is server dependant,
from our own experience, I'd suggest caution when restricting what can be
done at object creation time.  We did ( at one point ) consider an
inheritance system where setting access control on newly created objects
was controlled by parent inheritance. We ended up removing the feature
because our exploiters had great difficulty ensuring their applications
could install and use the directory. It required that everyone who could
install something needed to have an enormous amount of access to ensure
that they could instantiate the needed application objects.