CentOS - Feb 2017 - Centos7 and old Bind bug

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

On 02/11/2017 08:56 PM, Robert Moskowitz wrote:
> 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? 

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; };

On 02/12/2017 10:40 AM, Gordon Messmer wrote:
> 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. 

... 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.

On 02/12/2017 01:40 PM, Gordon Messmer wrote:
> On 02/11/2017 08:56 PM, Robert Moskowitz wrote:
>> 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? 
>
>
> 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.
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.
>
> 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; };
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)