OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Software Enhancements/4942
Full headers

From: quanah@OpenLDAP.org
Subject: configurable filter blocking
Compose comment
Download message
State:
0 replies:
4 followups: 1 2 3 4

Major security issue: yes  no

Notes:

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

Download message
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

Download message
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

Download message
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

Download message
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/


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org