Re: protecting dns in the ACM

[robert byrne <robert.byrne@Sun.COM>]

Rick,

I've tried to develop some of your points a bit further inline, but I
don't particulaly have the impression of having reached a conclusion.  I
think we are simply faced with a choice between adding to the overhead
of access control for the search operation and living with some
inconsistencies therein.

My impression at the moment is that such inconsistencies certainly
deserve a note in the draft, but are not fatal to the model, while the
performance and simplification gains are considerable.

Anyone got a counter example in the form of a scenario and access
control policy that would shatter my illusion ?

Rob.

Richard V Huber wrote:
> 
> The reason I thought that "abort subtree" was the expected behavior is
> the wording of the definition of the "t" permission in Section 4.2.1:
> 
>   t returnDN
> 
>   If granted, allows the distinguished name of the entry to be
>   disclosed in the operation result.
> 
> So if the requester does not have "t" permission for ou=eng in Rob's
> example, I expected that neither "ou=eng, o=sun.com" nor "cn=rob,
> ou=eng, o=sun.com" would be returned since both of them disclose the DN
> "ou=eng, o=sun.com" in the result.
> 
> If the interpretation in Rob's email is the desired result, then I
> think the definition of "t" permission needs to be clarified.  And is
> "t" permission really useful if it is so easy to get around it? It

I would say rather it's easy to make a configuration, such as the one in
my example, that doesn't make sense form a "protecting your dns point of
view".

> would seem that "t" only protects the DN of a leaf node, not any
> interior node.
> 

Well, a subtree with no "t" on any entry is protecting all the entries
in the subtree.  This sounds like a trivial case but in fact if some of
the leaves had aliases defined for them then you could see them, while
still protecting the ancestor nodes' dns.

Although it's not part of the ACM it's probably worth recalling that
aliasing is an additional mechanism for ptotecting dns.  Now, this could
still suffer from the same problem that a descendant node to which I had
full rights might reveal the existence of ancestors which are
aliased...but we could consider that a poor configuration.

> I have a few other comments embedded in Rob's email below.
> 
> Rick Huber
> 
> : Sender: Robert.Byrne@Sun.COM
> : From: robert byrne <robert.byrne@Sun.COM>
> : To: ietf-ldapext@netscape.com
> : Subject: protecting dns in the ACM
> :
> :
> : Rick raised a point about protecting dns in a recent mail:
> :
> : > And one other vaguely related question that came to mind after reading
> : > Rob's email.  He notes that "... the absence of a "v" or "b" permission
> : > at any point does not abort the search operation as a whole or even on
> : > a particular subtree."
> : >
> : > I have been assuming (and this seemed like a good time to check) that
> : > absence of a "t" permission DOES abort the search operation on a
> : > particular subtree, since returning the DN of any object further down
> : > in the tree would require that the DN of the object without "t"
> : > permission be returned.  Is that the generally accepted view?
> : >
> :
> : To show this problem here's a little tree where (all) means I have all
> : rights, (none) means I have no rights on that entry:
> :
> :       o=sun.com (all)
> :       |
> :       ou=eng  (none)
> :       |
> :       cn=rob  (all)
> :
> : Now, currently, if I do a subtree search with base o=sun.com then I will
> : get two entries: o=sun.com and cn=rob,ou=eng,o=sun.com.  The problem is
> : I am returned information about the ou=eng,o=sun.com entry, via the
> : entry cn=rob,ou=eng,o=sun.com, although in fact I have zero rights on
> : the ou=eng,o=sun.com entry.
> :
> : I guess the consistent way to fix this would be to require that before
> : returning the dn of an entry, A say, I also need the rights to see the
> : naming attribute of each entry in the tree above A.  So, in the example,
> : before returning cn=rob,ou=eng,o=sun.com I should check I have rights to
> : see ou in ou=eng,o=sun.com and o in o=sun.com.  This has the advantage
> : of being really consistent, it has the disadvantage that when I want to
> : see a given entry, I need to evaluate not just my rights on _that_
> : entry, but on on all the ancestors of that entry.  My suspision is that
> : most implementors would prefer this inconsistency to the cost of
> : checking this extra dependency.  For example, alot of directory
> : implementaions use indexing based loosely on the search filter to
> : generate candidate lists of entries to return--in such a scheme you will
> : not "naturally" visit all the ancestors of an entry, so I think the
> : "abort subtree" approach would not naturally fit those implementations.
> 
> The draft currently says (Section 5.2, note following discussion of the
> "b" permission in search operations) that the "b" permission allows the
> DN to be returned even if the requester does not have "r" permission
> for the naming attributes.  Would this suggestion mean that the "DN"
> entry-level permissions ("b", "t", etc.) go away and that we just
> depend on the permissions that apply to the naming attributes of the
> entry?  Or would "b" and "t" still have some purpose?

Actually this note is meant to highlight precisely the point you raised
about 
descendants giving away info about ancestors.  Maybe it was confusing to
put it with "b" and should have been placed with the "t" permission
description.
If we think of "b" as just a way to control browsing then I think we can
leave it aside for the purposes of thinking about protecting dns.

Dropping "t" entirely...well what is "t" doing ? "t" implies the right
to see the naming attribute of a given entry and the right to see the
naming attributes of all ancestors.  I guess we could drop it and
replace the current "t" requirement by requiring "r" on the naming
attribute of the entry.  In addition,  we would specify that having "r"
on the naming atribute on an entry would imply "r" on all the naming
attributes of the entry's ancestors.  However, in so far as the distinct
"t" permission helps roll up these two requirements I think I prefer to
keep it.

> 
> : So I think we have a consistency/performance trade off and this is why I
> : am currently not in favour of specifying an "abort subtree" type
> : behaviour...but if anyone else can see an efficient way of fixing the
> : consistency problem...
> 
> One cause of the inconsistency seems to be that we have entry-level
> permissions that sometimes override attribute-level permissions for
> naming attributes.  This may be a useful shorthand that makes
> implementations easier.  But if we decide it is useful to have these
> permissions we need to carefully define the interactions.

I agree with you--even if we don't explain every design descision in the
draft we should be as clear as possible about any "implied permissions"
and oddities in the way things behave.

> 
> : Rob.