Bug 1935101 - unbound-anchor doesn't respect system-wide defaults on which ports it can use and SELinux denied access on the udp_socket port 61000
Summary: unbound-anchor doesn't respect system-wide defaults on which ports it can use...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: unbound
Version: 33
Hardware: x86_64
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: aegorenk
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:0a6733b242fb09a5645f2ae15b7...
: 1836574 (view as bug list)
Depends On: 1667742
Blocks: 1837071
TreeView+ depends on / blocked
 
Reported: 2021-03-04 12:02 UTC by Tadej Janež
Modified: 2024-12-10 21:23 UTC (History)
27 users (show)

Fixed In Version: unbound-1.13.1-6.fc35 unbound-1.13.1-6.eln110
Clone Of: 1667742
Environment:
Last Closed: 2021-04-24 13:48:10 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Tadej Janež 2021-03-04 12:02:50 UTC
+++ 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?

--- 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.

Comment 1 Tadej Janež 2021-03-04 12:06:49 UTC
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.

Comment 2 aegorenk 2021-03-08 08:05:08 UTC
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

Comment 3 Tadej Janež 2021-03-08 09:04:09 UTC
(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!

Comment 4 Fedora Update System 2021-04-24 13:48:10 UTC
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.

Comment 5 Fedora Update System 2021-04-24 14:00:13 UTC
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.

Comment 6 aegorenk 2021-04-28 13:06:47 UTC
*** Bug 1836574 has been marked as a duplicate of this bug. ***


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