#2569 DNS records in LDAP are publicly accessible
Closed: Fixed None Opened 12 years ago by pspacek.

DNS part of LDAP tree should not be publicly readable. It is basically same as zone transfer allowed for whole world.

Only DNS administrators and DNS server principals (DNS/hostname) should have access to cn=dns. It would be useful to have separate "read dns records" right for support staff.

Additional info:
Example BIND LDAP plugin bind DN: {{{ krbprincipalname=DNS/dhcp-31-49.brq.redhat.com@E.ORG,cn=services,cn=accounts,dc=e,dc=org }}}


Note, I think it is a good idea to have an additional privilege.
However ...

Replying to [ticket:2569 pspacek]:

DNS part of LDAP tree should not be publicly readable. It is basically same as zone transfer allowed for whole world.

No, not the same thing, LDAP servers are not normally open outside the company boundaries, plus you can configure the whole directory to prevent anonymous access.
Let's not characterize it that way.

Only DNS administrators and DNS server principals (DNS/hostname) should have access to cn=dns. It would be useful to have separate "read dns records" right for support staff.

Additional info:
Example BIND LDAP plugin bind DN: {{{ krbprincipalname=DNS/dhcp-31-49.brq.redhat.com@E.ORG,cn=services,cn=accounts,dc=e,dc=org }}}

I think enforcing this kind of ACI should be optional, if possible.

Replying to [comment:2 simo]:

Note, I think it is a good idea to have an additional privilege.
However ...

Replying to [ticket:2569 pspacek]:

DNS part of LDAP tree should not be publicly readable. It is basically same as zone transfer allowed for whole world.

No, not the same thing, LDAP servers are not normally open outside the company boundaries, plus you can configure the whole directory to prevent anonymous access.
Let's not characterize it that way.

You are right. Described situation is "zone transfer allowed for whole company", not whole world.
I think it is still problem and far from best practice.

Disabling anonymous access is not enough in this case, because any user (even with lowest possible privileges) is still able read {{cn=dns}}.

DNS best practice is to restrict zone transfers to smallest possible set of users/hosts. Applied to our case:

Only DNS administrators and DNS server principals (DNS/hostname) should have access to cn=dns.

It would be useful to have separate "read dns records" right for support staff.

Additional info:
Example BIND LDAP plugin bind DN: {{{ krbprincipalname=DNS/dhcp-31-49.brq.redhat.com@E.ORG,cn=services,cn=accounts,dc=e,dc=org }}}

I think enforcing this kind of ACI should be optional, if possible.
I think is better to be resrictive by default. Administrator can any time simply change ACI to less restrictive.

Moving to next month iteration.

How to test:

New permission/aci should only allow users or hosts with appropriate permission or privilege to access the DNS tree in LDAP.

  1. Install a FreeIPA server with DNS support
  2. To test anonymous access (replace realm with your setting):

    ldapsearch -h localhost -b "cn=dns,dc=example,dc=com" -D "" -x

No DNS zone should be returned with the new ACI

  1. To verify that admin user can show the DNS tree:

    $ kinit admin
    $ ipa dnszone-find

DNS zones should be returned both with and without the new ACI

  1. To verify that normal users cannot view the DNS tree

    $ ipa user-add --first=Foo --last=Bar fbar
    $ ipa user-add
    $ ipa passwd fbar
    $ kinit fbar
    $ ipa dnszone-find

No DNS zone should be returned with the new ACI

  1. To verify that the new permission will allow non-admin user to view the DNS tree:

    $ kinit admin
    $ ipa privilege-add test --desc=tes
    $ ipa role-add test --desc=test
    $ ipa role-add-privilege --privileges=test
    $ ipa privilege-add-permission test --permissions="read dns entries"
    $ ipa role-add-member test --users=fbar

    $ kinit fbar
    $ ipa dnszone-find

DNS zones should be then returned

Patch freeipa-mkosek-245-forbid-public-access-to-dns-tree.patch sent for review

QE would like the ACI to use mixed case. We have agreed to make this change. My patch 1008 on freeipa-devel does this.

Metadata Update from @pspacek:
- Issue assigned to mkosek
- Issue set to the milestone: FreeIPA 2.2 Core Effort - 2012/04

7 years ago

Login to comment on this ticket.

Metadata