Subject: Re: ldapACI permissions

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 22 Mar 2000 11:12:13 -0700

I think it would be very hard and not very useful to allow one to have 'a' or 'd' rights, and not 'w'. This is especially true when the identity with 'a' rights doesn't have 'w' rights to mandatory attributes. I think certain rights should imply other rights. Maybe a set of 'implication rules' is needed. Something like:

Right     Implies
s         c
r         s, c
w         r, s, c <- not sure about that one
e         b
a         r, w, s, c, e, b
d         r, w, s, c, e, b

note that c and b don't imply any other right, and nothing implies a or d

Jim

>>> "Ryan Moats" <[email-masked]> 3/22/00 9:57:36 AM >>>
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: [email-masked] 
: To: [email-masked] (Richard V Huber)
: cc: [email-masked], [email-masked], [email-masked] 
: Subject: Re: ldapACI permissions

My Comments preceded by < djb >

Thanks,

Debora Byrne
Manager Secure Way Directory Config / User Interface
INet: [email-masked] 
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.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 22 Mar 2000 14:20:08 -0800

>I think it would be very hard and not very useful to allow one to have 'a' or 'd' rights, and not 'w'. This is especially true when the identity with 'a' rights doesn't have 'w' rights to mandatory…

This is just food for thought:

Have used access levels ("write" => "read" => "search" => "compare") in OpenLDAP
for some time, I have only found a couple of cases (such as disallow search
of readable attribute) where discrete permissions would have been extermely
useful.  These cases were enough to convince me that we should add support
for such.

What our devel code now supports both, it can be viewed (simplification):
	"write" is "=wrsc"
	"read" is "=rsc"
	"search" is "=sc"
	"compare" is "=c"

where the "=" sign is used to flag indicate the value is a discrete set of
permissions.  If you wanted to grant "r" but not "sc", you'd say "=r".

---

From: Ellen Stokes <[email-masked]>
Date: Thu, 23 Mar 2000 09:06:39 -0600

Although it is tempting to  'imply'  permissions as articulated in Jim's 
and Kurt's notes, this is
dangerous in that it allows some desired policies not be able to be 
expressed.  An example
is the administrator who needs the capability to reset a user's password 
(the admin needs 'write''),
but should not / must not have the capability to read or compare that 
user's password values.
The counter argument to this would be to additionally deny the admin read 
and compare.  But
that's more rules on the ACL.  Also, if you go back to the requriements 
document, it is stated
that 'safer is better' - in this context, explicitly specify the 
permissions so you know what you
get instead of implying permissions.  See S13, G1, and G2 in the 
requirements document.
Ellen

At 02:20 PM 3/22/00 -0800, Kurt D. Zeilenga wrote:
> >I think it would be very hard and not very useful to allow one to have 
> 'a' or 'd' rights, and not 'w'. This is especially true when the identity 
> with 'a' rights doesn't have 'w' rights to mandatory attributes. I think 
> certain rights should imply other rights. Maybe a set of 'implication 
> rules' is needed. Something like:
> >
>