Hide Forgot
+++ This bug was initially created as a clone of Bug #1667742 +++ 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 --- Additional comment from Leszek Matok on 2019-01-20 19:20:57 UTC --- 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. --- Additional comment from Dominik 'Rathann' Mierzejewski on 2019-01-24 08:41:41 UTC --- 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 --- Additional comment from Dominik 'Rathann' Mierzejewski on 2019-01-24 08:44:16 UTC --- I had selinux-policy-3.14.2-46.fc29.noarch installed on Jan 14th previously. --- Additional comment from Lukas Vrabec on 2019-01-28 15:34:54 UTC --- --- Additional comment from Lukas Vrabec on 2019-01-28 15:38:10 UTC --- Increasing priority, we have more tickets with same issue. @zpytela PTAL. --- Additional comment from Zdenek Pytela on 2019-05-15 07:08:00 UTC --- --- Additional comment from D. Hugh Redelmeier on 2019-05-23 05:02:26 UTC --- 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 --- Additional comment from Benny Amorsen on 2019-07-18 07:36:07 UTC --- Progress on this bug seems to have stalled. It looks very much like bug https://bugzilla.redhat.com/show_bug.cgi?id=1318224 which was fixed in RHEL 7 with commit 70c83cdcf23728ef416f46b8d19d07aa78ad7950. Unfortunately I do not know how to view Red Hat commits. If one of you could help out, that would be greatly appreciated. Thank you! --- Additional comment from BZ on 2019-12-02 01:50:55 UTC --- 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 --- Additional comment from Leszek Matok on 2019-12-28 12:46:02 UTC --- 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). --- Additional comment from Lukas Vrabec on 2020-01-09 21:28:24 UTC --- --- Additional comment from Lukas Vrabec on 2020-01-09 21:28:27 UTC --- --- Additional comment from Leszek Matok on 2020-01-10 13:27:21 UTC --- 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. --- Additional comment from Zdenek Pytela on 2020-03-16 18:39:40 UTC --- 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. --- Additional comment from Zdenek Pytela on 2020-03-17 15:33:49 UTC --- --- Additional comment from Petr Menšík on 2020-04-01 14:52:44 UTC --- 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. --- Additional comment from Petr Menšík on 2020-04-01 17:44:16 UTC --- 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 --- Additional comment from Zdenek Pytela on 2020-04-02 16:28:34 UTC --- --- Additional comment from D. Hugh Redelmeier on 2020-04-29 18:13:00 UTC --- 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 --- Additional comment from Paul Wouters on 2020-04-29 18:46:52 UTC --- 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 --- Additional comment from Zdenek Pytela on 2020-04-29 19:15:50 UTC --- 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. --- Additional comment from Paul Wouters on 2020-04-29 21:29:06 UTC --- ah yes indeed. This was fixed a long time ago: commit a147b9358d3ffe64711963514f1d856cb2f9461c Author: Paul Wouters <pwouters@redhat.com> 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 --- Additional comment from Fedora Update System on 2020-04-30 00:07:30 UTC --- FEDORA-2020-662591b32b has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-662591b32b --- Additional comment from Fedora Update System on 2020-04-30 00:08:00 UTC --- FEDORA-2020-99ffd3ff84 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-99ffd3ff84 --- Additional comment from Fedora Update System on 2020-04-30 04:13:53 UTC --- 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. --- Additional comment from Fedora Update System on 2020-04-30 04:59:00 UTC --- 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. --- Additional comment from Fedora Update System on 2020-05-02 04:03:16 UTC --- 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. --- Additional comment from Fedora Update System on 2020-05-08 04:00:22 UTC --- 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. --- Additional comment from Matt Domsch on 2020-05-14 05:01:25 UTC --- CentOS 8 has the same problem. How can we get this duplicated/fixed there also please? --- Additional comment from Paul Wouters on 2020-05-18 19:15:09 UTC --- I've cloned the bug for rhel8 --- Additional comment from Rob Newton on 2020-08-28 00:19:43 UTC --- (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. --- Additional comment from Zdenek Pytela on 2020-09-25 11:52:17 UTC --- 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? --- Additional comment from Rob Newton on 2020-09-29 02:28:04 UTC --- (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. --- Additional comment from Zdenek Pytela on 2020-09-29 04:56:42 UTC --- Rob, Please create a new bugzilla on selinux-policy for your issue.
I've just hit this on a vanilla Fedora 33 system which doesn't have unbound package installed, just unbound-libs: $ rpm -q unbound unbound-libs package unbound is not installed unbound-libs-1.13.1-1.fc33.x86_64 Hence, there is no unbound.conf or anything where outgoing ports to avoid would be specified. And from how I understood the previous converstion, unbound-anchor doesn't read the unbound.conf file anyway.
Hi, I'm already working on this one. I have feedback from upstream. I'm going to fix the review points and prepare patches for f33, f34, rawhide. Upstream discussion: https://github.com/NLnetLabs/unbound/issues/257 Upstream PR: https://github.com/NLnetLabs/unbound/pull/415
(In reply to aegorenk from comment #2) > Hi, I'm already working on this one. > I have feedback from upstream. I'm going to fix the review points and > prepare patches for f33, f34, rawhide. > > Upstream discussion: > https://github.com/NLnetLabs/unbound/issues/257 > > Upstream PR: > https://github.com/NLnetLabs/unbound/pull/415 Perfect, thanks for sharing this update!
FEDORA-2021-04ee69d25c has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-152f3259de has been pushed to the Fedora ELN stable repository. If problem still persists, please make note of it in this bug report.
*** Bug 1836574 has been marked as a duplicate of this bug. ***