#6501 Create a white-list of entries that can be accessible by anonymous ldapsearch
Opened by mbasti. Modified

We should have a white-list of entries that are accessible by anonymous ldapsearch and have test-suite that will be checking actual LDAP results against the whitelist, instead of blindly trust to permissions.

Current issues:

  • Annonymous ldapsearch leaks all IPA DNSSEC enabled zones, due the cn=keys container

    ldapsearch -x '(cn=keys)'
    dn: cn=keys,idnsname=ipa.test.,cn=dns,$SUFFIX

  • IPA servers hostnames leak from custodia containers

    cn=sig/vm-058-013.test.com,cn=dogtag,cn=custodia,...
    contains no keys or any data

  • cn=default,ou=profile,$SUFFIX shows some data

devmtg:

ab: we need to write a proposal which summarizes what is allowed for annonymous search - create a design page
honza: we did that few years ago
-> sync with it, review, add design page
Final goal: create whitelist of allowed entries, create test which tests the whitelist
* anonymous bind needed for solaris, MacOS, ...
Proposed plan:
* 4.5 check if regressions (permissions V2 design), at the end of 4.5 devel phase

Was agreed that this is not a CVE, thus published as a ticket.


A similar issue is:

if you give an user permissions to manage a single DNS zone, he suddenly can see all menu entries. he cant really edit in those other menu points. but

a) it can be confusing to users
b) the user can see more informations than i want them to see.

A note, the similar issue from comment 2 is completely unrelated because it describes Web UI behavior of authenticated user, i.e., not anonymous.

When user is assigned a role, Web UI changes its UI from self-service to admin view where everything is visible. Assigning DNS management permission doesn't give additional permission to the user therefore the user is able to get the "more information" either through CLI or API anyway even before assigning the user the role.

Metadata Update from @mbasti:
- Issue assigned to mbasti
- Issue set to the milestone: Future Releases

Metadata Update from @mbasti:
- Assignee reset

Metadata