Subject: ldapACI permissions

From: Ellen Stokes <[email-masked]>
Date: Tue, 21 Mar 2000 07:31:44 -0600

Rick/Ryan,

Page 12:

TECHNICAL:

                 e    EditDN   Edit an entry's DN
                 b    BrowseDN Browse an entry's DN

How is EditDN permission different from Write permission on the naming
attribute?  How is BrowseDN permission different from Search permission
on the naming attribute?  Can I have EditDN permission on the entry
without explicit Write permission on the naming attribute of the
entry?  What would it mean?

(EJS) EditDN and BrowseDN work at the entry level (DN) and equate to 
permissions
to modify/access the DN for ldapmodifyDN/ldapmodifyRDN/ldapSearch operations.
Write works at the attribute level on attributes.

And do we really need both Search and Compare permissions?
(EJS)  Yes, search and compare and 2 different operations.

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

Ellen

---

From: [email-masked] (Richard V Huber)
Date: Tue, 21 Mar 2000 10:02:43 -0500

Our comments are embedded in the copy of the email.

: Rick/Ryan,
: 
: 
: Page 12:
: 
: TECHNICAL:
: 
:                  e    EditDN   Edit an entry's DN
:                  b    BrowseDN Browse an entry's DN
: 
: How is EditDN permission different from Write permission on the naming
: attribute?  How is BrowseDN permission different from Search permission
: on the naming attribute?  Can I have EditDN permission on the entry
: without explicit Write permission on the naming attribute of the
: entry?  What would it mean?
: 
: (EJS) EditDN and BrowseDN work at the entry level (DN) and equate to 
: permissions
: to modify/access the DN for ldapmodifyDN/ldapmodifyRDN/ldapSearch operations.
: Write works at the attribute level on attributes.

But now you have two different permissions that apply to the same
data.  What is the precedence between them?  How should the server
interpret the case where there is EditDN permission on the entry
without explicit Write permission on the naming attribute of the
entry?  "deny" is the default when there is no ACI, and "deny" takes
precedence over "grant".  Would this mean that the DN cannot be
changed even though EditDN is granted?

: And do we really need both Search and Compare permissions?
: (EJS)  Yes, search and compare and 2 different operations.

OK.  The difference is so slight I had thought we might be able to use
one permission to cover both.

: >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.

: Ellen

Rick and Ryan

---

From: [email-masked]
Date: Tue, 21 Mar 2000 17:22:08 -0600

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.

< 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: [email-masked]
Date: Wed, 22 Mar 2000 08:24:03 -0500

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

---

From: "Ryan Moats" <[email-masked]>
Date: Wed, 22 Mar 2000 10:54:57 -0600

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

Thanks,

Debora Byrne

---

From: [email-masked]
Date: Wed, 22 Mar 2000 11:10:25 -0600

All,

<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.
<bb>
<bb> What we're really talking about here is the default policy which applies to
a newly created
<bb> object.
<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?

--bob

Bob Blakley
Chief Scientist
Tivoli SecureWay Business Unit

---

From: [email-masked]
Date: Wed, 22 Mar 2000 16:25:15 -0500

George_Robert_Blakley_III@                                                              
                    tivoli.com                        To:     [email-masked]                          
                                                      cc:     [email-masked], [email-masked] 
                    03/22/00 12:10 PM                 Subject:     Re: ldapACI permissions                  

All,

<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

---

From: [email-masked]
Date: Wed, 22 Mar 2000 17:22:59 -0600

My response < djb >

Thanks,

Debora Byrne

                George_Robert_Blakley_III@
                    tivoli.com                        To:
[email-masked]
                                                      cc:
[email-masked], [email-masked]
                    03/22/00 12:10 PM                 Subject:     Re:
ldapACI permissions

All,

<bb>

< djb > We were not specific enough in option 3.

In option 3, we allow all values to be set at object creation time.
 After creation, the attributes are controlled by the ldapACI attribute.

In option 1, the attributes which can be specified at object creation time
are
determined by an ancestor entries ldapACI. The creator would need 'write'
access to
the attributes (s)he wants to set. After creation time, they are controlled
by
the ldapACI attribute at the entry ( possibly the value is inherited from
an ancestor )

( Option 2 is similar to option 3 except that the ldapACI value can not set
)

--bob

Bob Blakley
Chief Scientist

---

From: [email-masked]
Date: Fri, 24 Mar 2000 10:12:19 -0500

So to recap what the options are:
     option 1 - "add", and "write" permission to the parent
     option 2 -  "add", except when ldapACI is specified, in which case the
"policyOwner" is also checked
     option 3 - "add".

I'm for the option 1.  The option 2 requires the implementation of the
"policyOwner" independent of ldapACI, which is not my interpretation of the
draft.
In either the option 2 or 3, there is not a way to restrict write access to
certain attributes when an entry is created.    As a system administrator I
may  want to give someone permissions to add an entry but does not
necessarily want to give the person to fill in certain attribute values at
the same time, for the same reason for not granting that person "write"
permissions on those attributes.

                    [email-masked]                                                         
                    m.com                To:     [email-masked]                
                                         cc:     [email-masked]                     
                    03/22/00             Subject:     Re: ldapACI permissions             
                    06:22 PM                                                              

My response < djb >

Thanks,

Debora Byrne

All,

<bb>

--bob

Bob Blakley
Chief Scientist