RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 807361 - DNS records in LDAP are publicly accessible
Summary: DNS records in LDAP are publicly accessible
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ipa
Version: 6.3
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Rob Crittenden
QA Contact: IDM QE LIST
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-27 15:29 UTC by Dmitri Pal
Modified: 2012-06-20 13:25 UTC (History)
4 users (show)

Fixed In Version: ipa-2.2.0-11.el6
Doc Type: Bug Fix
Doc Text:
Cause: All DNS records in IPA Directory Server instance are publicly accessible. Consequence: With a publicly accessible DNS tree in the Directory Server instance, anyone with an access to the server can get all DNS data as with a zone transfer which is otherwise restricted with access control rules. It is a common security practice to keep this information restricted to only a selected group of users. Change: Entire LDAP tree with DNS records is now accessible only to LDAP driver which feeds the data to the name server, admin users or users with a new permission called "Read DNS Entries". Result: Only permitted users can now access all DNS records in IPA Directory Server instance which increases a security of IPA server.
Clone Of:
Environment:
Last Closed: 2012-06-20 13:25:44 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0819 0 normal SHIPPED_LIVE ipa bug fix and enhancement update 2012-06-19 20:34:17 UTC

Description Dmitri Pal 2012-03-27 15:29:17 UTC
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/freeipa/ticket/2569

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,cn=services,cn=accounts,dc=e,dc=org }}}

Comment 1 Rob Crittenden 2012-04-02 18:27:13 UTC
fixed upstream

master: df13cdcb974e9f8b161be35fcef9651c2ffe0b5e

ipa-2-2: cf8f2f86ec52a1de90df6ea434463aa6417ef8ea

How to test (copied from trac):

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

    Install a FreeIPA server with DNS support
    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

    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

    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

    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

Comment 4 Namita Soman 2012-04-13 18:04:00 UTC
Verified using -
ipa-server-2.2.0-8.el6.x86_64

Steps taken:
kinit as admin
list zones - 2 zones returned
kinit as a new user
list zones - none returned
Add privilege with new permission - "read dns entries", add role with this privilege, add role to user
kinit as this user
can see the 2 zones

To complete this fix:
This new permission is named in all lowercase. It cannot be sorted alphabetically in Permission list. So please use naming conventions to match other Permisisons

NeedInfo:
Also - In UI, this permission doesn't display any details. All the other permissions display the permissions, type, attribute etc. This permission has a special type - System. Are there other permissions of this type? How would a user add a permission of this type?

Comment 6 Martin Kosek 2012-04-16 07:27:54 UTC
I don't agree. I specifically named the permission lower case in order to be consistent with other permissions for DNS entries:

# ipa permission-find dns
---------------------
5 permissions matched
---------------------
  Permission name: add dns entries
  Permissions: add
  Type: dnsrecord
  Granted to Privilege: DNS Administrators, DNS Servers

  Permission name: read dns entries
  Granted to Privilege: DNS Administrators, DNS Servers
  Permission Type: SYSTEM

  Permission name: remove dns entries
  Permissions: delete
  Type: dnsrecord
  Granted to Privilege: DNS Administrators, DNS Servers

  Permission name: update dns entries
  Permissions: write
  Attributes: idnsname, cn, idnsallowdynupdate, dnsttl, dnsclass, arecord, aaaarecord, a6record,
              nsrecord, cnamerecord, ptrrecord, srvrecord, txtrecord, mxrecord, mdrecord, hinforecord,
              minforecord, afsdbrecord, sigrecord, keyrecord, locrecord, nxtrecord, naptrrecord,
              kxrecord, certrecord, dnamerecord, dsrecord, sshfprecord, rrsigrecord, nsecrecord,
              idnsname, idnszoneactive, idnssoamname, idnssoarname, idnssoaserial, idnssoarefresh,
              idnssoaretry, idnssoaexpire, idnssoaminimum, idnsupdatepolicy, idnsallowquery,
              idnsallowtransfer, idnsallowsyncptr, idnsforwardpolicy, idnsforwarders
  Type: dnsrecord
  Granted to Privilege: DNS Administrators, DNS Servers


NEEDINFO: the permission is of SYSTEM type because it should not be modified by user. The underlying LDAP ACI is not placed in $SUFFIX, but rather in cn=dns,$SUFFIX and thus permission plugin cannot read its attributes.

This is the ACI:
# ldapsearch -Y GSSAPI -h localhost -b cn=dns,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com -s base aci
...
# dns, idm.lab.bos.redhat.com
dn: cn=dns,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
aci: (targetattr = "*")(version 3.0; acl "No access to DNS tree without a perm
 ission"; deny (read,search,compare) (groupdn != "ldap:///cn=admins,cn=groups,
 cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com") and (groupdn != "ldap:///
 cn=read dns entries,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=bos,dc=redhat,dc=
 com");)

And this is a list of other examples of SYSTEM permissions (user is not supposed to add or modify these permissions):


# ipa permission-find | grep -B 3 -A 1 SYSTEM
  Permission name: Add Replication Agreements
  Granted to Privilege: Replication Administrators
  Permission Type: SYSTEM

--

  Permission name: Modify Replication Agreements
  Granted to Privilege: Replication Administrators
  Permission Type: SYSTEM

--

  Permission name: read dns entries
  Granted to Privilege: DNS Administrators, DNS Servers
  Permission Type: SYSTEM

--

  Permission name: Remove Replication Agreements
  Granted to Privilege: Replication Administrators
  Permission Type: SYSTEM

Comment 7 Rob Crittenden 2012-04-16 12:44:04 UTC
Ok, I agree with Martin. Better to be consistent.

Comment 9 Rob Crittenden 2012-04-20 20:13:09 UTC
After discussion with QE we decided to go ahead and fix this and see if we can fix the existing DNS permissions as well to use mixed case.

Comment 11 Martin Kosek 2012-04-25 11:01:08 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause: All DNS records in IPA Directory Server instance are publicly accessible.
Consequence: With a publicly accessible DNS tree in the Directory Server instance, anyone with an access to the server can get all DNS data as with a zone transfer which is otherwise restricted with access control rules. It is a common security practice to keep this information restricted to only a selected group of users.
Change: Entire LDAP tree with DNS records is now accessible only to LDAP driver which feeds the data to the name server, admin users or users with a new permission called "Read DNS Entries".
Result: Only permitted users can now access all DNS records in IPA Directory Server instance which increases a security of IPA server.

Comment 12 Namita Soman 2012-05-10 13:27:13 UTC
Verified using ipa-server-2.2.0-12.el6.x86_64

  Permission name: Read DNS Entries
  Granted to Privilege: DNS Administrators, DNS Servers
  Permission Type: SYSTEM

For other dns permissions that are in lowercase as mentioned in comment 6, there is another bug for it - bug 815828

Comment 14 errata-xmlrpc 2012-06-20 13:25:44 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0819.html


Note You need to log in before you can comment on or make changes to this bug.