Description of problem: It appears to be random in normal operation, however the amount of SETroubleshoot popups increases tenfold when there's a problem with my Internet connection. SELinux is preventing unbound from 'name_bind' accesses on the udp_socket port 61000. ***** Plugin catchall_boolean (89.3 confidence) suggests ****************** Aby allow system to run with NIS Then należy powiadomić o tym SELinuksa włączając zmienną logiczną „nis_enabled”. Do setsebool -P nis_enabled 1 ***** Plugin catchall (11.6 confidence) suggests ************************** Aby unbound powinno mieć domyślnie name_bind dostęp do port 61000 udp_socket. Then proszę to zgłosić jako błąd. Można utworzyć lokalny moduł polityki, aby umożliwić ten dostęp. Do można tymczasowo zezwolić na ten dostęp wykonując polecenia: # ausearch -c 'unbound' --raw | audit2allow -M my-unbound # semodule -X 300 -i my-unbound.pp Additional Information: Source Context system_u:system_r:named_t:s0 Target Context system_u:object_r:port_t:s0 Target Objects port 61000 [ udp_socket ] Source unbound Source Path unbound Port 61000 Host (removed) Source RPM Packages Target RPM Packages Policy RPM <Nieznane> Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 4.19.15-300.fc29.x86_64 #1 SMP Mon Jan 14 16:32:35 UTC 2019 x86_64 x86_64 Alert Count 153 First Seen 2019-01-19 12:18:47 CET Last Seen 2019-01-20 19:50:52 CET Local ID 588d3bab-f53c-4768-bd4b-77e173c18a7a Raw Audit Messages type=AVC msg=audit(1548010252.865:2263): avc: denied { name_bind } for pid=3344 comm="unbound" src=61000 scontext=system_u:system_r:named_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=udp_socket permissive=0 Hash: unbound,named_t,port_t,udp_socket,name_bind Additional info: component: selinux-policy reporter: libreport-2.9.7 hashmarkername: setroubleshoot kernel: 4.19.15-300.fc29.x86_64 type: libreport
I was surprised to find bug 1259766 from Fedora 23 and bug 1318224 from RHEL7 with basically the same story. And suddenly this hit my F29, maybe 2 weeks ago? I was waiting for an update, but nothing is showing up, so here's a bug submission.
Description of problem: This appeared on first boot today, with no internet connection initially. Then I connected to a Bluetooth-tethered connection via my mobile phone. $ rpm -q unbound selinux-policy unbound-1.8.3-2.fc29.x86_64 selinux-policy-3.14.2-47.fc29.noarch $ rpm -qai unbound selinux-policy | egrep 'Name|Install Date' Name : selinux-policy Install Date: Tue 22 Jan 2019 14:28:46 CET Name : unbound Install Date: Wed 19 Dec 2018 15:12:39 CET However, it seems the first AVC denial happened on Jan 20th, so before the latest seliux-policy install: time->Sun Jan 20 16:29:43 2019 type=AVC msg=audit(1547998183.614:360): avc: denied { name_bind } for pid=1143 comm="unbound" src=61000 scontext=system_u:system_r:named_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=udp_socket permissive=0 ---- time->Wed Jan 23 23:16:46 2019 type=AVC msg=audit(1548281806.716:288): avc: denied { name_bind } for pid=1200 comm="unbound" src=61000 scontext=system_u:system_r:named_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=udp_socket permissive=0 ... ---- time->Thu Jan 24 09:31:39 2019 type=AVC msg=audit(1548318699.452:273): avc: denied { name_bind } for pid=1229 comm="unbound" src=61000 scontext=system_u:system_r:named_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=udp_socket permissive=0 Version-Release number of selected component: selinux-policy-3.14.2-47.fc29.noarch Additional info: reporter: libreport-2.9.7 hashmarkername: setroubleshoot kernel: 4.20.3-200.fc29.x86_64 type: libreport
I had selinux-policy-3.14.2-46.fc29.noarch installed on Jan 14th previously.
*** Bug 1669731 has been marked as a duplicate of this bug. ***
Increasing priority, we have more tickets with same issue. @zpytela PTAL.
*** Bug 1710225 has been marked as a duplicate of this bug. ***
Description of problem: SELinux is preventing unbound from 'name_bind' accesses on the udp_socket port 61000. Although I'm on Fedora 30, this looks a lot like bug 1259766 Version-Release number of selected component: selinux-policy-3.14.3-37.fc30.noarch Additional info: reporter: libreport-2.10.0 hashmarkername: setroubleshoot kernel: 5.0.16-300.fc30.x86_64 type: libreport
This comment was flagged as spam, view the edit history to see the original text if required.
Just for what it's worth, the problem persists in fully updated Fedora 31 with selinux-policy-targeted-3.14.4-40.fc31.noarch. It seems to cause all attempts to resolve names with unbound (whether the subject name in is DNSSEC-protected or not) to fail: [bgz@nepia ~]$ dig +dnssec net. @127.0.0.1 ; <<>> DiG 9.11.13-RedHat-9.11.13-2.fc31 <<>> +dnssec net. @127.0.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 51526 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;net. IN A ;; Query time: 116 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Dec 02 10:47:52 JST 2019 ;; MSG SIZE rcvd: 32
Confirmed, this still happens in F31 (currently selinux-policy-targeted-3.14.4-43.fc31.noarch). To Benny from comment 8, from what I can tell, RHEL 7.3 (bug 1318224) simply added: corenet_udp_bind_all_ephemeral_ports(named_t) corenet_tcp_bind_all_ephemeral_ports(named_t) to the policy... and this is still present in Fedora's policy. But please note: back in 2015, the exception was hitting system_u:object_r:ephemeral_port_t:s0 (note: ephemeral_port_t) and now for the same port 61000 it's system_u:object_r:port_t:s0 (note: no ephemeral_ prefix). So in the mean time, this port's label changed which brought back the issue. Interestingly, someone tried to work around it already from unbound's config side: In /etc/unbound/unbound.conf we can see: # Only ephemeral ports are allowed by SElinux outgoing-port-permit: 32768-60999 (...) # Our SElinux policy does not allow non-ephemeral ports to be used outgoing-port-avoid: 0-32767 But this does NOT prevent unbound from trying to use port 61000. In fact, first line is basically ignored (all it does it telling unbound to use all ports in this range even if they're reseved), leaving ports 61000-65535 enabled by default. So to test, I've added another line that goes: outgoing-port-avoid: 61000 And if that helps, perhaps the bug should be changed to component unbound, as the default config clearly doesn't achieve what I think was intended by the author (based on the comments).
*** Bug 1787061 has been marked as a duplicate of this bug. ***
*** Bug 1714318 has been marked as a duplicate of this bug. ***
I hit another port (with yet another label) meanwhile, so now I've changed the additional line to exclude the whole range: outgoing-port-avoid: 61000-65535 Since doing that, I haven't gotten a single SELinux exception.
Switching component. Unbound folks, We have a few reports that unbound/unbound-anchor tries to connect to port 61000/udp; in the last update there is alos another port number mentioned. Is this intentional? This the default local port range: # sysctl net.ipv4.ip_local_port_range net.ipv4.ip_local_port_range = 32768 60999 Feel free to switch the component back if there is a need to adjuse the selinux-policy.
*** Bug 1806559 has been marked as a duplicate of this bug. ***
Sure, this is initialized in util/config_file.c; init_outgoing_availports function. It does not use net.ipv4.ip_local_port_range, but just range from 1024 up, excluding 49152-49408 and assigned IANA ports. So nothing by default blocks higher ports. Since we have just permit, it allows explicitly lower ports. But high ports remain enabled, unless outgoing-port-avoid: is used another time. Fix of unbound would be just configuration file. But unbound-anchor does not read any configuration file. This is issue in unbound configuration. Maybe also in lack of using system-wide settings.
It seems just outgoing-port-avoid is required, but from below and above default range. Permit does not help. outgoing-port-avoid: 0-32767 outgoing-port-avoid: 61000-65535
*** Bug 1779672 has been marked as a duplicate of this bug. ***
Status report: I still have this problem even though my system is Fedora 31 with all updates. The rest of this message is the contents of the SETroubleshoot Details Window. SELinux is preventing unbound from name_bind access on the udp_socket port 61000. ***** Plugin catchall_boolean (89.3 confidence) suggests ****************** If you want to allow nis to enabled Then you must tell SELinux about this by enabling the 'nis_enabled' boolean. Do setsebool -P nis_enabled 1 ***** Plugin catchall (11.6 confidence) suggests ************************** If you believe that unbound should be allowed name_bind access on the port 61000 udp_socket by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'unbound' --raw | audit2allow -M my-unbound # semodule -X 300 -i my-unbound.pp Additional Information: Source Context system_u:system_r:named_t:s0 Target Context system_u:object_r:port_t:s0 Target Objects port 61000 [ udp_socket ] Source unbound Source Path unbound Port 61000 Host redeye Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-3.14.4-50.fc31.noarch Local Policy RPM selinux-policy-targeted-3.14.4-50.fc31.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name redeye Platform Linux redeye 5.6.6-200.fc31.x86_64 #1 SMP Tue Apr 21 15:34:22 UTC 2020 x86_64 x86_64 Alert Count 2502 First Seen 2019-07-08 02:05:59 EDT Last Seen 2020-04-29 13:20:43 EDT Local ID 161ecf22-4cf4-43e4-b34a-133472679804 Raw Audit Messages type=AVC msg=audit(1588180843.745:415): avc: denied { name_bind } for pid=963 comm="unbound" src=61000 scontext=system_u:system_r:named_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=udp_socket permissive=0 Hash: unbound,named_t,port_t,udp_socket,name_bind
ahh the selinux ephemeral port range changed :) ephemeral_port_t tcp 32768-60999 ephemeral_port_t udp 32768-60999 I will push a fix that changes the unbound.conf option eg curent: outgoing-port-permit: 32768-65535 new: outgoing-port-permit: 32768-60999
Paul, You are right. The ephemeral_port_t range changed during the life cycle of Fedora 29 to match the default value of the net.ipv4.ip_local_port_range tunable: # semanage port -l | grep ephemeral_port_t ephemeral_port_t tcp 32768-60999 ephemeral_port_t udp 32768-60999 # sysctl net.ipv4.ip_local_port_range net.ipv4.ip_local_port_range = 32768 60999 However, the upper bound previously was 61000, not 65535.
ah yes indeed. This was fixed a long time ago: commit a147b9358d3ffe64711963514f1d856cb2f9461c Author: Paul Wouters <pwouters> Date: Thu Jul 7 19:22:06 2016 +0300 - Fix upper port range to 60999 because that's what selinux allows I'll add the outgoing-port-avoid: 61000-65535
FEDORA-2020-662591b32b has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-662591b32b
FEDORA-2020-99ffd3ff84 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-99ffd3ff84
FEDORA-2020-662591b32b has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-662591b32b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-662591b32b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-99ffd3ff84 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-99ffd3ff84` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-99ffd3ff84 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-662591b32b has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-99ffd3ff84 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report.
CentOS 8 has the same problem. How can we get this duplicated/fixed there also please?
I've cloned the bug for rhel8
(In reply to Fedora Update System from comment #27) > FEDORA-2020-662591b32b has been pushed to the Fedora 32 stable repository. > If problem still persists, please make note of it in this bug report. This is still happening on Fedora 32: SELinux is preventing unbound-anchor from name_bind access on the udp_socket port 61000.
Rob, The latest version is unbound-1.10.1-1.fc32.x86_64 and it contains in the configuration: # Only ephemeral ports are allowed by SElinux outgoing-port-permit: 32768-60999 ... # IANA-assigned port numbers. # If multiple outgoing-port-permit and outgoing-port-avoid options # are present, they are processed in order. # Our SElinux policy does not allow non-ephemeral ports to be used outgoing-port-avoid: 0-32767 outgoing-port-avoid: 61000-65535 so it should not try to bind to port 61000. Did you modify unbound.conf so that the new config was created with the .rpmnew suffix?
(In reply to Zdenek Pytela from comment #32) > Rob, > > The latest version is unbound-1.10.1-1.fc32.x86_64 and it contains in the > configuration: > > # Only ephemeral ports are allowed by SElinux > outgoing-port-permit: 32768-60999 > ... > # IANA-assigned port numbers. > # If multiple outgoing-port-permit and outgoing-port-avoid options > # are present, they are processed in order. > # Our SElinux policy does not allow non-ephemeral ports to be used > outgoing-port-avoid: 0-32767 > outgoing-port-avoid: 61000-65535 > > so it should not try to bind to port 61000. Did you modify unbound.conf so > that the new config was created with the .rpmnew suffix? Zdenek, I am using that same version unbound.x86_64 1.10.1-1.fc32. I have not edited a file unbound.conf. My system was a recent clean install of F32. Running 'locate' does not find 'unbound.conf' anywhere.
Rob, Please create a new bugzilla on selinux-policy for your issue.