CentOS7 And Old Bind Bug

Home » CentOS » CentOS7 And Old Bind Bug
CentOS 6 Comments

This is my new CentOS7 DNS server.

In logwatch I am seeing:

**Unmatched Entries**
dispatch 0xb4378008: open_socket(0.0.0.0#5546) -> permission denied: continuing: 1 Time(s)
dispatch 0xb4463008: open_socket(::#1935) -> permission denied: continuing: 1 Time(s)
dispatch 0xb4464440: open_socket(::#8554) -> permission denied: continuing: 1 Time(s)
dispatch 0xb4464440: open_socket(::#8614) -> permission denied: continuing: 1 Time(s)
dispatch 0xb4465008: open_socket(::#1935) -> permission denied: continuing: 1 Time(s)
dispatch 0xb4465440: open_socket(0.0.0.0#4321) -> permission denied: continuing: 1 Time(s)
dispatch 0xb4465878: open_socket(0.0.0.0#2605) -> permission denied: continuing: 1 Time(s)
dispatch 0xb4465878: open_socket(0.0.0.0#4444) -> permission denied: continuing: 1 Time(s)
dispatch 0xb4465878: open_socket(0.0.0.0#8611) -> permission denied: continuing: 1 Time(s)
dispatch 0xb4466008: open_socket(0.0.0.0#1935) -> permission denied: continuing: 1 Time(s)
dispatch 0xb4466008: open_socket(0.0.0.0#5546) -> permission denied: continuing: 1 Time(s)
dispatch 0xb4466008: open_socket(0.0.0.0#8611) -> permission denied: continuing: 1 Time(s)
dispatch 0xb4466440: open_socket(0.0.0.0#2605) -> permission denied: continuing: 1 Time(s)
dispatch 0xb4466440: open_socket(0.0.0.0#4444) -> permission denied: continuing: 1 Time(s)
dispatch 0xb4466878: open_socket(0.0.0.0#1935) -> permission denied: continuing: 1 Time(s)
dispatch 0xb4466878: open_socket(0.0.0.0#8610) -> permission denied: continuing: 1 Time(s)
dispatch 0xb4467440: open_socket(0.0.0.0#8613) -> permission denied: continuing: 1 Time(s)
dispatch 0xb4467440: open_socket(0.0.0.0#8614) -> permission denied: continuing: 1 Time(s)

etc.

This seems to be bug 1103439 which was ‘fixed’ for CentOS6.

What should I do about this? Is there a SELinux policy to apply or should I the avoid upd-ports option in Bind?

thank you

6 thoughts on - CentOS7 And Old Bind Bug

  • It looks like that bug was assigned to the selinux-policy component, where it was CLOSED NOTABUG, and then mistakenly marked CLOSED ERRATA.

    The solution is probably to specify the allowed ports. However, I must be reading something wrong, because on my system, it looks like named_t is allowed to use those ports.

    # sesearch -A -s named_t | grep port | grep bind

    …indicates that named_t is allowed to bind to both unreserved ports and ephemeral ports.

    # semanage port -l | grep unreserved_port_t unreserved_port_t tcp 61001-65535, 1024-32767
    unreserved_port_t udp 61001-65535, 1024-32767
    # semanage port -l | grep ephemeral_port_t ephemeral_port_t tcp 32768-61000
    ephemeral_port_t udp 32768-61000

    I’m not seeing those errors logged, either, so maybe your system differs from mine. If I’m misreading, hopefully someone will chime in to clarify.

    It’s probably safe to specify some range of higher numbered ports:

    use-v4-udp-ports { range 10240 65535; };
    use-v6-udp-ports { range 10240 65535; };

  • … Also, it might be useful to get the AVCs on your system. The bug entry indicated that you’d need to enable debugging (semodule -DB, and later use semodule -B to disable debugging) to get them. While in debugging mode, audit.log should contain confirmation that SELinux is blocking the port use. That log entry should tell us more about how to address the problem.

  • ? What do I install for this? BTW, this is a CentOS7-armv7 image, but that should not make a difference in base C7 component availability.

  • I get:

    # semanage port -l | grep unreserved_port_t unreserved_port_t tcp 61001-65535, 1024-32767
    unreserved_port_t udp 61001-65535, 1024-32767

    # semanage port -l | grep ephemeral_port_t ephemeral_port_t tcp 32768-61000
    ephemeral_port_t udp 32768-61000

    so same semanage results, but different logwatch events. BTW, my internal DNS is not getting these, so some external ‘hit’ is triggering it.

    But that is not the ports that I am seeing in logwatch:

    **Unmatched Entries**
    dispatch 0xb4463008: open_socket(::#8554) -> permission denied: continuing: 1 Time(s)
    dispatch 0xb4463008: open_socket(::#8614) -> permission denied: continuing: 1 Time(s)
    dispatch 0xb4464008: open_socket(::#8613) -> permission denied: continuing: 1 Time(s)
    dispatch 0xb4465008: open_socket(::#4444) -> permission denied: continuing: 1 Time(s)
    dispatch 0xb4465440: open_socket(0.0.0.0#5546) -> permission denied: continuing: 2 Time(s)
    dispatch 0xb4465440: open_socket(0.0.0.0#8554) -> permission denied: continuing: 1 Time(s)
    dispatch 0xb4465878: open_socket(0.0.0.0#2605) -> permission denied: continuing: 1 Time(s)
    dispatch 0xb4465878: open_socket(0.0.0.0#4444) -> permission denied: continuing: 2 Time(s)
    dispatch 0xb4465878: open_socket(0.0.0.0#8610) -> permission denied: continuing: 1 Time(s)
    dispatch 0xb4465878: open_socket(0.0.0.0#8613) -> permission denied: continuing: 1 Time(s)
    dispatch 0xb4466008: open_socket(0.0.0.0#4444) -> permission denied: continuing: 1 Time(s)
    dispatch 0xb4466008: open_socket(0.0.0.0#8554) -> permission denied: continuing: 1 Time(s)
    dispatch 0xb4466008: open_socket(0.0.0.0#8613) -> permission denied: continuing: 1 Time(s)
    dispatch 0xb4466440: open_socket(0.0.0.0#1935) -> permission denied: continuing: 1 Time(s)
    dispatch 0xb4466440: open_socket(0.0.0.0#8610) -> permission denied: continuing: 1 Time(s)
    dispatch 0xb4466878: open_socket(0.0.0.0#8610) -> permission denied: continuing: 1 Time(s)
    dispatch 0xb4467008: open_socket(0.0.0.0#8611) -> permission denied: continuing: 1 Time(s)
    dispatch 0xb4467440: open_socket(0.0.0.0#1935) -> permission denied: continuing: 2 Time(s)
    dispatch 0xb4467440: open_socket(0.0.0.0#4444) -> permission denied: continuing: 1 Time(s)
    dispatch 0xb4467440: open_socket(0.0.0.0#8613) -> permission denied: continuing: 1 Time(s)
    dispatch 0xb4467440: open_socket(0.0.0.0#8614) -> permission denied: continuing: 1 Time(s)
    dispatch 0xb4468008: open_socket(0.0.0.0#4444) -> permission denied: continuing: 1 Time(s)

  • Yes, I know. The work-around in the bug report specifies which ports to exclude, but it doesn’t include some of the ports you saw in your logs, so it won’t solve the problem entirely. If you instead specify the ports that are allowed, and use a higher range of ports, the work-around should be more reliable.

  • You don’t have to install anything. You’d just temporarily disable
    “dontaudit” rules by running “semodule -BD”. Give named time to log additional “permission denied” errors, and then look for related AVC
    messages in /var/log/audit/audit.log. Send those logs to the list and we can troubleshoot further.

LEAVE A COMMENT