Viewing Software Enhancements/4942
Full headers

Major security issue: yes  no

Notes:
request for enhancement
Notification:

Date: Mon, 30 Apr 2007 16:13:46 GMT
From: quanah@OpenLDAP.org
To: openldap-its@openldap.org
Subject: configurable filter blocking

Full_Name: Quanah Gibson-Mount
Version: NA
OS: NA
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (171.66.155.86)


In reading through the documentation for Fedora DS, I saw an interesting feature
where you can, at the slapd level, disable the ability for clients to execute
filters when the attribute(s) being filtered on are not indexed.  This seems an
interesting feature to me, but I think it could be more worthwhile to make it a
bit more configurable, where you could block certain filter types from being
used, regardless of whether or not they were indexed, and expanded to only
pertain to particular subtrees.

For example, I may want to block subfinal indices on the "suAffiliation"
attribute in the cn=people,dc=stanford,dc=edu tree.

Just food for thought.

--Quanah

Followup 1

From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
Date: Mon, 30 Apr 2007 19:54:26 +0200
To: quanah@openldap.org
Cc: openldap-its@openldap.org
Subject: Re: (ITS#4942) configurable filter blocking

quanah@OpenLDAP.org writes:
> In reading through the documentation for Fedora DS, I saw an
> interesting feature where you can, at the slapd level, disable the
> ability for clients to execute filters when the attribute(s) being
> filtered on are not indexed.

What's the motivation for this?  I've thought about suggesting similar
features (or maybe even suggested it, I don't remember) - but so far
the "unchecked" limit has proved a better way for my purposes.

How does it work with complex filters?  E.g. (&(cn=foo)(mail=*))
where cn is indexed and finds the relevant entries, mail=*
eliminates the 0.1% mailless users.  Should this succeed if mail
has no presence index?  If no, what's the advantage of forbidding
it?  If yes, how do you stop (&(objectClass=person)(mail=*))?

> This seems an interesting feature to me, but I think it could be
> more worthwhile to make it a bit more configurable, (...)
> For example, I may want to block subfinal indices on the
> "suAffiliation" attribute in the cn=people,dc=stanford,dc=edu tree.

I can see an access control reason for doing that, though users
might get trivially around it by appending a '*' to the filter.

And I do use sizelimit and the "unchecked" limit as a crude form of
access control, as well as to ensure a good response time.  But it
remains crude, since it's not what an index is for - it's basically
just an optimization.

-- 
Regards,
Hallvard

Followup 2

From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
Date: Mon, 30 Apr 2007 20:03:17 +0200
To: quanah@openldap.org
Cc: openldap-its@openldap.org
Subject: Re: (ITS#4942) configurable filter blocking

quanah@OpenLDAP.org writes:
> For example, I may want to block subfinal indices on the
> "suAffiliation" attribute in the cn=people,dc=stanford,dc=edu tree.

I should have added: Unless you've got a better answer than me for
why this is better than the "unchecked" limit, it might be more
useful to block "suAffiliation" from getting a "subfinal" index.
Then use the "unchecked" limit to block too general searches.

-- 
Regards,
Hallvard

Followup 3

Date: Mon, 30 Apr 2007 22:32:58 -0700 (PDT)
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: h b furuseth <h.b.furuseth@usit.uio.no>
Cc: openldap-its@openldap.org
Subject: Re: (ITS#4942) configurable filter blocking

----- "h b furuseth" <h.b.furuseth@usit.uio.no> wrote:
> quanah@OpenLDAP.org writes:
> > For example, I may want to block subfinal indices on the
> > "suAffiliation" attribute in the cn=people,dc=stanford,dc=edu tree.
> 
> I should have added: Unless you've got a better answer than me for
> why this is better than the "unchecked" limit, it might be more
> useful to block "suAffiliation" from getting a "subfinal" index.
> Then use the "unchecked" limit to block too general searches.

Hi Hallvard,

My reasoning comes from this:  At my previous job we had a tree rooted at
"dc=stanford,dc=edu".  Controlling the indexing to allow/block certain types of
searches has been very important, and the directory well tuned to that purpose. 
The following subtrees are what exist: cn=people, cn=accounts, and
cn=organizations.  cn=organizations is the newest subtree, and additional
indexing had to be added on attributes that used to be indexed differently in
the person tree.  There is no desire to split the trees apart into their own
databases, but indexing is per database (not per subtree).

For example, displayName used to be indexed "eq" only.  Now with organizations,
we need to change the index to "eq,sub".  So it would be nice to block substring
filters of displayName in the cn=people tree, etc.

--Quanah

Followup 4

Date: Tue, 01 May 2007 01:11:27 -0700
From: Howard Chu <hyc@symas.com>
To: quanah@zimbra.com
CC: openldap-its@openldap.org
Subject: Re: (ITS#4942) configurable filter blocking

quanah@zimbra.com wrote:
> ----- "h b furuseth" <h.b.furuseth@usit.uio.no> wrote:
>> quanah@OpenLDAP.org writes:
>>> For example, I may want to block subfinal indices on the
>>> "suAffiliation" attribute in the cn=people,dc=stanford,dc=edu tree.
>> I should have added: Unless you've got a better answer than me for
>> why this is better than the "unchecked" limit, it might be more
>> useful to block "suAffiliation" from getting a "subfinal" index.
>> Then use the "unchecked" limit to block too general searches.
> 
> Hi Hallvard,
> 
> My reasoning comes from this:  At my previous job we had a tree rooted at
"dc=stanford,dc=edu".  Controlling the indexing to allow/block certain types of
searches has been very important, and the directory well tuned to that purpose. 
The following subtrees are what exist: cn=people, cn=accounts, and
cn=organizations.  cn=organizations is the newest subtree, and additional
indexing had to be added on attributes that used to be indexed differently in
the person tree.  There is no desire to split the trees apart into their own
databases, but indexing is per database (not per subtree).
> 
> For example, displayName used to be indexed "eq" only.  Now with
organizations, we need to change the index to "eq,sub".  So it would be nice to
block substring filters of displayName in the cn=people tree, etc.
> 
> --Quanah

Should be simple enough to write an overlay that can be configured with 
a URI and filter types to block. Just return Unwilling to Perform for 
any matching patterns. Certainly not something that needs to be added to 
the core code.

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/