Bug 1312972 - BIND - open_socket / permission denied warnings
BIND - open_socket / permission denied warnings
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: selinux-policy (Show other bugs)
7.2
x86_64 Linux
low Severity low
: rc
: ---
Assigned To: Lukas Vrabec
Milos Malik
: Reopened
Depends On:
Blocks: 1393066
  Show dependency treegraph
 
Reported: 2016-02-29 11:35 EST by Joshua Hirsh
Modified: 2017-08-01 11:10 EDT (History)
17 users (show)

See Also:
Fixed In Version: selinux-policy-3.13.1-134.el7
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-01 11:10:10 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 1103439 None CLOSED open_socket / permission dennied warnings 2018-06-21 09:50 EDT
Red Hat Product Errata RHBA-2017:1861 normal SHIPPED_LIVE selinux-policy bug fix update 2017-08-01 13:50:24 EDT

  None (edit)
Description Joshua Hirsh 2016-02-29 11:35:11 EST
Description of problem: Bug ID 1103439 still exists in RHEL 7.2. With an out of the box installation, BIND will be prevented from using specific high numbered ports due to SELinux policy and will log entries such as: open_socket(0.0.0.0#1935) -> permission denied: continuing


Version-Release number of selected component (if applicable):
bind-9.9.4-29.el7_2.2.x86_64
selinux-policy-3.13.1-60.el7_2.3.noarch

How reproducible:
Requires a heavy DNS load (or force BIND to use specific ports blocked by SELinux)

Steps to Reproduce:
1. Run BIND as a service configured to use-v4-udp-ports that conflict with SELinux policy (1935, 2605, 4321, 4444, 8611, 8613, etc)
2. Attempt to resolve queries


Actual results (logged from BIND category default + general):
29-Feb-2016 10:36:54.450 dispatch: dispatch 0x7f461012ba70: open_socket(0.0.0.0#8611) -> permission denied: continuing
29-Feb-2016 12:20:15.226 dispatch: dispatch 0x7f4610129bd0: open_socket(0.0.0.0#8613) -> permission denied: continuing
29-Feb-2016 12:44:28.444 dispatch: dispatch 0x7f461012f7b0: open_socket(0.0.0.0#4444) -> permission denied: continuing
29-Feb-2016 12:59:14.938 dispatch: dispatch 0x7f461012a1f0: open_socket(0.0.0.0#1935) -> permission denied: continuing
29-Feb-2016 13:01:24.927 dispatch: dispatch 0x7f461012f7b0: open_socket(0.0.0.0#1935) -> permission denied: continuing


Thanks
Comment 2 Miroslav Grepl 2016-04-29 04:48:10 EDT
Joshua,
are there AVC msgs if you try to reproduce it?

1. reproduce
2. run

# ausearch -m avc,user_avc -ts recent

Thank you.
Comment 3 Joshua Hirsh 2016-06-09 10:15:14 EDT
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
Comment 4 Tom G. Christensen 2016-06-13 09:13:54 EDT
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.
Comment 6 Doug Wussler 2016-07-29 15:32:39 EDT
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?
Comment 7 Doug Wussler 2016-07-29 16:31:20 EDT
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?
Comment 8 Doug Wussler 2016-07-29 16:33:17 EDT
Did not intend for my "needinfo" to be canceled.
Comment 9 Joshua Hirsh 2016-08-01 08:58:07 EDT
(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
Comment 10 ilmostro7 2016-10-06 12:20:10 EDT
pingback to bug 1198917
Comment 11 Lukas Vrabec 2017-03-28 08:08:05 EDT
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.
Comment 12 Joshua Hirsh 2017-03-28 08:20:07 EDT
Lukas, these are DEFAULT configurations. The specific port examples are defined to highlight the issue.
Comment 15 Phil Perry 2017-04-16 05:22:29 EDT
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.
Comment 16 Lukas Vrabec 2017-04-17 08:21:32 EDT
Phil, 

What is version of selinux-policy package on tested system?
Comment 17 Phil Perry 2017-04-17 13:28:28 EDT
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.
Comment 18 Milos Malik 2017-06-02 14:30:21 EDT
# 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.
Comment 21 Rob Foehl 2017-06-20 14:35:34 EDT
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.
Comment 22 errata-xmlrpc 2017-08-01 11:10:10 EDT
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

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