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