Re: More access checking inconsistencies? (Was: (ITS#3639) Inconsistent access checking in back-shell?)

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

With back-dnssrv, I see little point in having access controls.
The server is just echoing information it obtains from DNS,
which is generally publicly accessible information*.  I'm not sure
I didn't disable ACLs for this backend... that's
likely what I should have done.  Probably was just lazy.
back-dnssrv was (and I think still) experimental.

If one considers split DNS issues (inside v. outside) (which
I didn't), one could argue that some basic access controls being
useful.  Maybe just entry level controls.  But I guess I would
argue that if you have split DNS, then you likely should have
split back-dnssrv (one inside, one outside) to deal with it.

A few additional comments...

At 07:33 AM 4/9/2005, Pierangelo Masarati wrote:
>[moved to -devel from ITS#3639 for further discussion]
>
>ando@sys-net.it wrote:
>
>>On a related note: back-dnssrv is returning referrals, or referral entries when the manageDSAit control is used, but no access control is performed.  I guess we should add the capability to control what is returned (which is already provided for entries by the frontend, but none is in place with respect to referrals or search references), and also the capability to control who can access the feature, by checking for "search" access to a dummy object representing the searchBase.  This may be of use when a dnssrv request is issued with respect to a DSA that can auth users, say, stored in a local database before they access the dnssrv service.
>> 
>
>Let me elaborate a bit more about this: if we search an entry that actually is a referral object, and we use the manageDSAit control, the entry itself and some of the "ref" values may not be returned because of ACLs.
>
>However, if we search a subordinate of the referral object, or if we try a different operation targeting a subordinate of the referral object, we get a referral with all the available values; the same occurs in case a search is returing a search reference, i.e. all referal values are returned.
>
>I see an inconsistency, and the opportunity to add extra access checking to the referral values that are returned.  Note that this may be of use not only with respect to security, which is usually the main concern when discussing access control, but also with respect to operativity.  
>Consider the case of a public service that can be accessed both from outside and from inside an organization, which contains referrals to servers that hold subordinates of the naming context.  References to servers outside a firewall should not be returned to clients contacting the server from inside, and viceversa.  Of course, there might be security concerns as well.
>
>I suggest we use access checking when referrals are returned.  A check at "entry" pseudo-attribute would determine if the referral is to be returned at all, while each "ref" value should check whether a given reference can be returned.  I don't have a clear idea about what access privilege to test for.  Maybe a reasonable approach could be to test for the privilege related to the operation that is being attempted; e.g. if a referral is returned in response to an "add", "write" (or "add") permission could be checked.

That would not be sensible.  Only "read" is needed to return a value.
And, in error cases, one could argue that only "disclose" is needed.

>If we deal with the referral at the frontend level, we don't have an entry; in this case, we could simply build a dummy entry consisting of the "matchedDN" (if present) and the references as "ref" attributes.  If access checking is delegated to the be_chk_referrals() hook, the entry would be available, unless the default referral is being returned.  In the latter case, I have no ideas at the moment.
>
>p.
>
>
>   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497