Upgrade to 1.2.11.15-22 gives problems with OR in searchfilter

[389-ds-bot]

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/47556

• Created at 2013-10-10 19:03:26 by gobi
• Closed as Invalid
• Assigned to lkrispen (@elkris)

---

After upgrading from 1.2.11.15 B2013.100.2247 to 1.2.11.15 B2013.238.2155 i found this problem.

If you search with the following filter, and do a search in a group that has an entry with the attribute memberuid: user1, you get the correct result.

(&(objectClass=posixGroup)(memberuid=user1))

If you add an OR in the filter for an attribute not listed in the aci, e.g, you dont have permission to read it:

(&(objectClass=posixGroup)(|(uniqueMember=uid=user1,ou=users)(memberuid=user1)))

You dont get a correct answer.

[389-ds-bot]

Comment from rmeggins (@richm) at 2013-10-10 19:27:17

Please provide your acis.

[389-ds-bot]

Comment from gobi at 2013-10-10 20:30:22

At the Toplevel (i have stripped some ou's in the ticket, but there are no other aci on the way to ou=users (can provide the full dn if that would be to any help)):

(targetattr = "memberUid || uid ||  uidNumber || gidNumber || homeDirectory || gecos || objectClass || cn || givenName || sn || loginShell || afshomedirectory ||  macaddress || authAuthority") (version 3.0;acl "Anonymous access from XXX.XXX.*";allow (read,compare,search)(userdn = "ldap:///anyone") and (ip="XXX.XXX.*.*");)

If i add uniquemember to that aci, the OR statement in the filter works.

[389-ds-bot]

Comment from lkrispen (@elkris) at 2013-10-15 15:46:23

The behaviour in 1.2.11.15-22 is correct and was broken before.

The RHDS documentation says in
13.3.3.3. Rights Required for LDAP Operations
Searching for entries:

Grant search permission on each attribute type used in the search filter.
Grant read permission on attribute types used in the entry. 

This was not enforced in previous releases and could be used to guess values of attributes without read access to them.

[389-ds-bot]

Comment from pantzer at 2013-10-15 17:40:20

Search permissions should be enforced. But they should be enforced for each attribute separately. Search for a attribute that I do not have search rights for should be replaced by false in the search string before the search is executed.

As is is now we have to have an ACL that gives everyone search rights to all attributes. We can't change the search strings for all possible clients. Many don't even have configurable search strings!

If we have an ACL that grants search rights for all clients for all attributes we have a security problem as values can be guessed even if we do not have read rights. This is not good.

If you still say that values can be guessed if I can have attributes in a search string that I do not have search right to (even if search for just that attribute is denied) please give an example for how that could happen!

[389-ds-bot]

Comment from lkrispen (@elkris) at 2013-10-15 18:03:30

Replying to [comment:5 pantzer]:

Search permissions should be enforced. But they should be enforced for each attribute separately. Search for a attribute that I do not have search rights for should be replaced by false in the search string before the search is executed.

It is not as simple as that. Acis are evaluated after the search is executed and the candidate listz is determined. It cannot be done before, because the set of applicable acis depends on the entry itself and its location in the tree.

If you still say that values can be guessed if I can have attributes in a search string that I do not have search right to (even if search for just that attribute is denied) please give an example for how that could happen!

After the candidate list is built based on the search filter, for each candidate entry the

• search filter is verified and
• access control is verifies.
  For AND and OR filters in the current implementation this is done independently and in prvious releases access was granted if search rights for at least one filter attribut existed - this allowed to guess values if only the filter component of an attribute without access matched.
  I will not go into further details describing how to exploit this.

There might be an other solution, which would require reworking the process of filter usage, verification and access control evaluation, but would require a major change.
The current fix is compliant with tehe specification.

[389-ds-bot]

Comment from lkrispen (@elkris) at 2013-10-28 18:36:49

I have created ticket 47576 for future improvement, will close this for now

[389-ds-bot]

Comment from lkrispen (@elkris) at 2017-02-11 22:52:24

Metadata Update from @elkris:

• Issue assigned to elkris
• Issue set to the milestone: N/A