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

[Pierangelo Masarati <ando@sys-net.it>]

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

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