ExecSum: add to unbound.conf: outgoing-port-avoid: 61000-65535
+++ 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>
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?