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:43 PM, Gordon Messmer wrote:
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.
? 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.
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.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 02/12/2017 10:50 AM, Robert Moskowitz wrote:
? What do I install for this?
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.
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 unreservedports 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)
On 02/12/2017 10:56 AM, Robert Moskowitz wrote:
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:
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.
Thanks Gordon...
On 02/12/2017 03:15 PM, Gordon Messmer wrote:
On 02/12/2017 10:56 AM, Robert Moskowitz wrote: >>> 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: > > > 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.
No more port messages in logwatch.
Now to learn about GeoIP and what all those failures are that show up in logwatch!
-
Gordon Messmer -
Robert Moskowitz