Bug 1312972

Joshua,
are there AVC msgs if you try to reproduce it?

1. reproduce
2. run

# ausearch -m avc,user_avc -ts recent

Thank you.

Sorry for the late response. The denies are not displayed, since they fall under the dontaudit rules. This is how I just reproduced it with a clean install.

[root@DNSTest log]# uname -a
Linux DNSTest 3.10.0-327.18.2.el7.x86_64 #1 SMP Thu May 12 11:03:55 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

[root@DNSTest log]# rpm -q bind selinux-policy selinux-policy-targeted
bind-9.9.4-29.el7_2.3.x86_64
selinux-policy-3.13.1-60.el7_2.3.noarch
selinux-policy-targeted-3.13.1-60.el7_2.3.noarch


In /etc/named.conf:
  use-v4-udp-ports { 1935; 2605; 4321; 6514; range 8610 8614; };
  use-v6-udp-ports { 1935; 2605; 4321; 6514; range 8610 8614; };


Disable dontaudit rules: semodule -DB


[root@DNSTest log]# nslookup www.google.ca 127.0.0.1
Server:         127.0.0.1
Address:        127.0.0.1#53

** server can't find www.google.ca: SERVFAIL



[root@DNSTest log]# ausearch -m avc,user_avc -ts recent | tail -8
----
time->Thu Jun  9 11:04:29 2016
type=SYSCALL msg=audit(1465484669.544:747): arch=c000003e syscall=49 success=no exit=-13 a0=208 a1=7fe6346627a0 a2=10 a3=12 items=0 ppid=1 pid=9956 auid=4294967295 uid=25 gid=25 euid=25 suid=25 fsuid=25 egid=25 sgid=25 fsgid=25 tty=(none) ses=4294967295 comm="named" exe="/usr/sbin/named" subj=system_u:system_r:named_t:s0 key=(null)
type=AVC msg=audit(1465484669.544:747): avc:  denied  { name_bind } for  pid=9956 comm="named" src=8611 scontext=system_u:system_r:named_t:s0 tcontext=system_u:object_r:ipp_port_t:s0 tclass=udp_socket
----
time->Thu Jun  9 11:04:29 2016
type=SYSCALL msg=audit(1465484669.544:748): arch=c000003e syscall=49 success=no exit=-13 a0=209 a1=7fe6346627a0 a2=10 a3=12 items=0 ppid=1 pid=9956 auid=4294967295 uid=25 gid=25 euid=25 suid=25 fsuid=25 egid=25 sgid=25 fsgid=25 tty=(none) ses=4294967295 comm="named" exe="/usr/sbin/named" subj=system_u:system_r:named_t:s0 key=(null)
type=AVC msg=audit(1465484669.544:748): avc:  denied  { name_bind } for  pid=9956 comm="named" src=8610 scontext=system_u:system_r:named_t:s0 tcontext=system_u:object_r:ipp_port_t:s0 tclass=udp_socket


[root@DNSTest log]# aureport -a | grep named | grep denied | grep 11:04:29 | wc -l
623


[root@DNSTest log]# tail -3 messages
Jun  9 11:04:29 DNSTest named[9955]: dispatch 0x7fe62c0af1b0: open_socket(0.0.0.0#8614) -> permission denied: continuing
Jun  9 11:04:29 DNSTest named[9955]: dispatch 0x7fe62c0af1b0: open_socket(0.0.0.0#8611) -> permission denied: continuing
Jun  9 11:04:29 DNSTest named[9955]: dispatch 0x7fe62c0af1b0: open_socket(0.0.0.0#8610) -> permission denied: continuing


Thanks
-Joshua

I'm seeing the same on two CentOS 5 hosts that was just upgraded to CentOS 7.

After a few hours of running:
# sed -n '/open_socket/ s/..*#\([0-9]*\)).*/\1/p' /var/log/messages.1 | sort -u | xargs echo
1935 2605 4321 4444 5546 8554 8610 8611 8612 8613 8614

Disabling the dontaudit rules results in visible AVCs like Joshua has shown.

Yes, we are seeing this too.  RHEL 7.2, current on all patches.  After disabling dontaudit rules with semodule -DB:

ausearch -m avc -ts recent | audit2allow -w

type=AVC msg=audit(1469819571.231:4300): avc:  denied  { name_bind } for  pid=1775 comm="named" src=8613 scontext=system_u:system_r:named_t:s0 tcontext=system_u:object_r:ipp_port_t:s0 tclass=udp_socket

	Was caused by:
		Missing type enforcement (TE) allow rule.


it shows up clearly in named.general log file too:

<root@system:0 /var/log/named>$ grep permission named.general | tail
29-Jul-2016 14:00:35.492 dispatch: warning: dispatch 0x7f073412d910: open_socket(0.0.0.0#8613) -> permission denied: continuing
29-Jul-2016 14:08:36.323 dispatch: warning: dispatch 0x7f073412ccd0: open_socket(0.0.0.0#61000) -> permission denied: continuing

Is there a suggested work-around... with detailed implementation instructions?

And why is named NOT denied access on so many other ports?  A packet capture shows named is responding out many neighboring ports.  Why are those ports not also blocked by SELinux?

Did not intend for my "needinfo" to be canceled.

(In reply to Doug Wussler from comment #6)
> Is there a suggested work-around... with detailed implementation
> instructions?

Hi Doug,

 One possible work-around is to specifically identify the ports that BIND is able to use, selecting a range that doesn't conflict with the policies, until the problem is corrected:

options {
        use-v4-udp-ports { range 9000 65535; };
        use-v6-udp-ports { range 9000 65535; };
};

Cheers
-Joshua

pingback to bug 1198917

Joshua, 

It looks that these ports are custom not default defined in /etc/named.conf, in that case it should be fixed by local policy instead of changes in selinux-policy package.

Lukas, these are DEFAULT configurations. The specific port examples are defined to highlight the issue.

I'm seeing this issue too on udp ports 4444 and 5546, with default configuration on RHEL7. The issue only became apparent when switching SELinux from permissive to enforcing.

Is there any way to see a full list of ports named is not allowed to use as listed in the SELinux policy? Looking back through bugzilla this issue seems to have cropped up numerous times over the years. Is there a boolean to allow named to bind all udp ports? I don't see anything obvious.

Phil, 

What is version of selinux-policy package on tested system?

This is a fully updated RHEL7.3 system:

# rpm -q selinux-policy
selinux-policy-3.13.1-102.el7_3.16.noarch

I'm also seeing udp ports 8554 and 8610-8614 blocked too.

# cat /var/log/messages | grep open_socket
Apr 15 12:34:00 quad named[1168]: dispatch 0x7fbaa40f1130: open_socket(0.0.0.0#5546) -> permission denied: continuing
Apr 15 16:48:27 quad named[1168]: dispatch 0x7fbaa40f1750: open_socket(0.0.0.0#4444) -> permission denied: continuing
Apr 16 10:21:23 quad named[1168]: dispatch 0x7fbaa40df770: open_socket(0.0.0.0#8612) -> permission denied: continuing
Apr 16 17:29:06 quad named[1168]: dispatch 0x7fbaa40e2e90: open_socket(0.0.0.0#8554) -> permission denied: continuing
Apr 16 22:58:12 quad named[1168]: dispatch 0x7fbaa40e2e90: open_socket(0.0.0.0#8610) -> permission denied: continuing
Apr 17 03:09:12 quad named[1168]: dispatch 0x7fbaa40e2250: open_socket(0.0.0.0#8610) -> permission denied: continuing


If you have an updated selinux-policy package available, I'm happy to help test.

# rpm -qa selinux\*
selinux-policy-doc-3.13.1-157.el7.noarch
selinux-policy-mls-3.13.1-157.el7.noarch
selinux-policy-devel-3.13.1-157.el7.noarch
selinux-policy-targeted-3.13.1-157.el7.noarch
selinux-policy-3.13.1-157.el7.noarch
selinux-policy-minimum-3.13.1-157.el7.noarch
#

named_t is allowed to name_bind each UDP port mentioned in the description except for 4321:

# seinfo --portcon=4321
	portcon tcp 4321 system_u:object_r:whois_port_t:s0
	portcon udp 4321 system_u:object_r:whois_port_t:s0
	portcon tcp 1024-32767 system_u:object_r:unreserved_port_t:s0
	portcon udp 1024-32767 system_u:object_r:unreserved_port_t:s0
# sesearch -s named_t -t whois_port_t -c udp_socket -A -C -D 
Found 6 semantic av rules:
   dontaudit named_t reserved_port_type : udp_socket name_bind ; 
   allow named_t port_type : udp_socket { recv_msg send_msg } ; 
ET dontaudit nsswitch_domain defined_port_type : udp_socket name_bind ; [ nis_enabled ]
ET allow nsswitch_domain port_type : udp_socket recv_msg ; [ nis_enabled ]
ET allow nsswitch_domain port_type : udp_socket send_msg ; [ nis_enabled ]
ET dontaudit nsswitch_domain port_type : udp_socket name_bind ; [ nis_enabled ]

#

The name_bind operation for this port is dontaudit-ed.

Can confirm this is still an issue on all current RHEL/CentOS 7 and Fedora 24/25/26 targeted SELinux policies, despite the claims to the contrary in bug 1103439, bug 1198917, and bug 1272835.

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.

https://access.redhat.com/errata/RHBA-2017:1861