Description of problem: This seems to pop up randomly after I login. SELinux is preventing rpcbind from 'name_bind' accesses on udp_socket port 64657. ***** 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 (100. confidence) suggests ************************** If you believe that rpcbind should be allowed name_bind access on the port 64657 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 'rpcbind' --raw | audit2allow -M my-rpcbind # semodule -X 300 -i my-rpcbind.pp Additional Information: Source Context system_u:system_r:rpcbind_t:s0 Target Context system_u:object_r:unreserved_port_t:s0 Target Objects port 64657 [ udp_socket ] Source rpcbind Source Path rpcbind Port 64657 Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.14.4-35.fc31.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 5.2.17-200.fc30.x86_64 #1 SMP Mon Sep 23 13:42:32 UTC 2019 x86_64 x86_64 Alert Count 1 First Seen 2019-09-29 18:43:22 CEST Last Seen 2019-09-29 18:43:22 CEST Local ID 749756c7-f3a7-4c61-b175-981a9d5401c9 Raw Audit Messages type=AVC msg=audit(1569775402.560:337): avc: denied { name_bind } for pid=36266 comm="rpcbind" src=64657 scontext=system_u:system_r:rpcbind_t:s0 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=udp_socket permissive=0 Hash: rpcbind,rpcbind_t,unreserved_port_t,udp_socket,name_bind Version-Release number of selected component: selinux-policy-3.14.4-35.fc31.noarch
The first advice from catchall_boolean plugin is correct. Do: # setsebool -P nis_enabled 1 Please let us know if the SELinux denial appears again.
I've realized that when this popped up and I was filing it it was already 4 days old and looking at dnf logs it was after I upgraded Fedora from 30 to 31. It hasn't been reported since that even though I haven't set the value until now.
Because the nis_enabled boolean is by default turned on.
Sorry, my mistake. The boolean is by default turned off.
We see this a lot recently in Cockpit tests[1] on Fedora 30 images. ``` audit: type=1400 audit(1573031093.482:321): avc: denied { name_bind } for pid=7416 comm="rpcbind" src=61302 scontext=system_u:system_r:rpcbind_t:s0 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=udp_socket permissive=0 ``` I haven't dug deeper when exactly this happens, but if it is needed, please let me know. [1] example failure: https://209.132.184.41:8493/logs/pull-12971-20191106-084747-86f484cb-cockpit-project-cockpit--fedora-30-firefox/log.html#185
*** Bug 1773430 has been marked as a duplicate of this bug. ***
Similar problem has been detected: Not sure what caused this hashmarkername: setroubleshoot kernel: 5.3.11-300.fc31.x86_64 reason: SELinux is preventing rpcbind from 'name_bind' accesses on the udp_socket port 62126. type: libreport
The advise says: # setsebool -P nis_enabled 1 But I don't use NIS here.
This was closed without an explanation -- unless "The boolean is by default turned off." was supposed to be that. We still see that countless times [1], on Fedora 31/32/33, this is a default Fedora install without NIS. [1] https://github.com/cockpit-project/bots/issues/118
On Fedora 33 there is a variant of this now, with "unbound-anchor" instead of "rpcbind": audit: type=1400 audit(2091398401.751:700): avc: denied { name_bind } for pid=15025 comm="unbound-anchor" src=61000 scontext=system_u:system_r:named_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=udp_socket permissive=0
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Can somebody please update Version: here to 33 or rawhide given comment #9 and comment #10?
Confirmed, this is still very much alive: https://github.com/cockpit-project/bots/issues/118
Regarding the comment#10, the fix is already prepared. Check the link: https://bugzilla.redhat.com/show_bug.cgi?id=1794531 In other cases, you need to enable the nis_enabled boolean when you are using the rpcbind service, because the port number varies.
(In reply to Richard Fiľo from comment #14) > > In other cases, you need to enable the nis_enabled boolean when you are > using the rpcbind service, because the port number varies. So why is this boolean called "nis_enabled" when it has nothing to do with NIS. I don't run NIS here and I keep getting that recommendation. Does it need to be renamed to something that doesn't indicate something specific such as NIS?
The nis_enabled boolean contains a lot of rules and in this case it fixes this issue as well.
Steve, In newer Fedoras rpcbind name-binds to random (unpredictable) ports. I've read through bz#1559324 and the result was the behaviour changed in F29: commit 2e9c289246c647e25649914bdb0d9400c66f486e (tag: pcbind-0_2_5-rc4) Author: Steve Dickson <steved> Date: Wed Aug 15 10:22:36 2018 -0400 rpcbind: Disable remote calls by default Added a new configuration flag --enable-rmtcalls which will be needed to enable the remote call functionality. This also stops rpcbind from opening up random listening ports. Signed-off-by: Steve Dickson <steved> but it seems to be back again. Does it mean the current rpcbind version requires this access, even without changes to default configuration?
*** Bug 1861372 has been marked as a duplicate of this bug. ***
*** Bug 1889164 has been marked as a duplicate of this bug. ***
*** Bug 1847226 has been marked as a duplicate of this bug. ***
(In reply to Zdenek Pytela from comment #17) > Steve, > > In newer Fedoras rpcbind name-binds to random (unpredictable) ports. I've > read through bz#1559324 and the result was the behaviour changed in F29: > > commit 2e9c289246c647e25649914bdb0d9400c66f486e (tag: pcbind-0_2_5-rc4) > Author: Steve Dickson <steved> > Date: Wed Aug 15 10:22:36 2018 -0400 > > rpcbind: Disable remote calls by default > > Added a new configuration flag --enable-rmtcalls > which will be needed to enable the remote call > functionality. > > This also stops rpcbind from opening up random > listening ports. > > Signed-off-by: Steve Dickson <steved> > > but it seems to be back again. > > Does it mean the current rpcbind version requires this access, even without > changes to default configuration? Yes... I did turn remote calls (which use that random listening port) back on by default due to bug 1630672 because it did break NIS and something called Kodia Maybe there is a better way to enable that listening port?? I did not turn it back on in RHEL so maybe there are doing something else in there....
Steve, Thank you for the clarification. I see 2 options: - we allow rpcbind name-bind *all* udp ports in selinux-policy - rpcbind will bind only to ephemeral ports: this is allowed by default to any process (even without turning the nis_enable SELinux boolean on which is off by default) # sysctl net.ipv4.ip_local_port_range net.ipv4.ip_local_port_range = 32768 60999 I cannot assess which option is the best for rpcbind regarding usability & security.
(In reply to Zdenek Pytela from comment #22) > Steve, > > Thank you for the clarification. I see 2 options: > - we allow rpcbind name-bind *all* udp ports in selinux-policy > - rpcbind will bind only to ephemeral ports: this is allowed by default to At this point I believe rpcbind is using ephemeral ports... * * Dynamic port range as defined in RFC 6335 Section 6. * This range avoids all IANA-assigned service port * numbers. */ enum { LOWPORT = 49152, ENDPORT = 65534, NPORTS = ENDPORT - LOWPORT + 1, }; and the semodule -X 300 -i my-rpcbind.pp is showing port 64657 is being used. According to 6335 Section 6 the ephemeral port range is 49152-65535 > any process (even without turning the nis_enable SELinux boolean on which is > off by default) > > # sysctl net.ipv4.ip_local_port_range > net.ipv4.ip_local_port_range = 32768 60999 How is the range generated?
(In reply to Steve Dickson from comment #23) > (In reply to Zdenek Pytela from comment #22) > > Steve, > > > > Thank you for the clarification. I see 2 options: > > - we allow rpcbind name-bind *all* udp ports in selinux-policy > > - rpcbind will bind only to ephemeral ports: this is allowed by default to > At this point I believe rpcbind is using ephemeral ports... > * > * Dynamic port range as defined in RFC 6335 Section 6. > * This range avoids all IANA-assigned service port > * numbers. > */ > enum { > LOWPORT = 49152, > ENDPORT = 65534, > NPORTS = ENDPORT - LOWPORT + 1, > }; > > and the semodule -X 300 -i my-rpcbind.pp is showing port 64657 is > being used. According to 6335 Section 6 the ephemeral port range is > 49152-65535 > > > any process (even without turning the nis_enable SELinux boolean on which is > > off by default) > > > > # sysctl net.ipv4.ip_local_port_range > > net.ipv4.ip_local_port_range = 32768 60999 > How is the range generated? This is predefined in kernel. As the values are customizable using sysctl, I suppose the range in application should also be retrieved using the kernel function inet_get_local_port_range() or some wrapper. net/ipv4/af_inet.c 1814 static __net_init int inet_init_net(struct net *net) 1815 { 1816 /* 1817 * Set defaults for local port range 1818 */ 1819 seqlock_init(&net->ipv4.ip_local_ports.lock); 1820 net->ipv4.ip_local_ports.range[0] = 32768; 1821 net->ipv4.ip_local_ports.range[1] = 60999; 1822 net/ipv4/inet_connection_sock.c 124 void inet_get_local_port_range(struct net *net, int *low, int *high) 125 { 126 unsigned int seq; 127 128 do { 129 seq = read_seqbegin(&net->ipv4.ip_local_ports.lock); 130 131 *low = net->ipv4.ip_local_ports.range[0]; 132 *high = net->ipv4.ip_local_ports.range[1]; 133 } while (read_seqretry(&net->ipv4.ip_local_ports.lock, seq)); 134 } 135 EXPORT_SYMBOL(inet_get_local_port_range);
Similar problem has been detected: Unknown, but not running NIS. hashmarkername: setroubleshoot kernel: 5.9.16-200.fc33.x86_64 package: selinux-policy-targeted-3.14.6-33.fc33.noarch reason: SELinux is preventing rpcbind from 'name_bind' accesses on the udp_socket port 61044. type: libreport
Similar problem has been detected: No idea if this should be allowed or not. But reporting anyway. hashmarkername: setroubleshoot kernel: 5.10.7-200.fc33.x86_64 package: selinux-policy-targeted-3.14.6-34.fc33.noarch reason: SELinux is preventing rpcbind from 'name_bind' accesses on the udp_socket porte 62359. type: libreport
Similar problem has been detected: This happens every morning immediately after logon into gnome. hashmarkername: setroubleshoot kernel: 5.10.9-201.fc33.x86_64 package: selinux-policy-targeted-3.14.6-34.fc33.noarch reason: SELinux is preventing rpcbind from 'name_bind' accesses on the udp_socket port 62471. type: libreport
Same here on F33, not using NIS (but NFS), with: rpcbind-1.2.5-5.rc1.fc33.3.x86_64 selinux-policy-targeted-3.14.6-34.fc33.noarch
Oops, doozy on my end, please ignore.
Switching the component to rpcbind. IMHO this bug should be fixed with setting the port range to match the values in kernel.
Similar problem has been detected: This happens at boot: selinux-policy-3.14.6-35.fc33.noarch selinux-policy-minimum-3.14.6-35.fc33.noarch selinux-policy-targeted-3.14.6-35.fc33.noarch libselinux-3.1-2.fc33.x86_64 hashmarkername: setroubleshoot kernel: 5.10.23-200.fc33.x86_64 package: selinux-policy-targeted-3.14.6-35.fc33.noarch reason: SELinux is preventing rpcbind from 'name_bind' accesses on the udp_socket porte 63561. type: libreport
Similar problem has been detected: Boot the system and install updates. 2021-06-03T15:55:00+0200 DDEBUG timer: transaction: 14225 ms 2021-06-03T15:55:00+0200 DEBUG Completion plugin: Generating completion cache... 2021-06-03T15:55:01+0200 DEBUG Aktualisiert: cdparanoia-10.2-37.fc33.x86_64 2021-06-03T15:55:01+0200 DEBUG Aktualisiert: cdparanoia-libs-10.2-37.fc33.x86_64 2021-06-03T15:55:01+0200 DEBUG Aktualisiert: libtirpc-1.2.6-4.rc4.fc33.x86_64 2021-06-03T15:55:01+0200 DEBUG Aktualisiert: python3-pillow-7.2.0-6.fc33.x86_64 2021-06-03T15:55:01+0200 DEBUG Aktualisiert: qbittorrent-1:4.3.5-1.fc33.x86_64 2021-06-03T15:55:01+0200 DEBUG Aktualisiert: rb_libtorrent-1.2.13-1.fc33.x86_64 2021-06-03T15:55:01+0200 DEBUG Aktualisiert: rng-tools-6.12-3.fc33.x86_64 2021-06-03T15:55:01+0200 DEBUG Aktualisiert: rpcbind-1.2.6-0.fc33.x86_64 2021-06-03T15:55:01+0200 DEBUG Aktualisiert: tigervnc-license-1.11.0-11.fc33.noarch 2021-06-03T15:55:01+0200 DEBUG Aktualisiert: tigervnc-server-minimal-1.11.0-11.fc33.x86_64 2021-06-03T15:55:01+0200 DEBUG Installiert: rtl-sdr-0.6.0-8.fc33.x86_64 2021-06-03T15:55:01+0200 INFO Fertig. 2021-06-03T15:55:01+0200 DDEBUG Cleaning up. hashmarkername: setroubleshoot kernel: 5.12.8-200.fc33.x86_64 package: selinux-policy-targeted-3.14.6-37.fc33.noarch reason: SELinux is preventing rpcbind from 'name_bind' accesses on the udp_socket Port 65483. type: libreport
I just saw this on Fedora 33, but not Fedora 34. Was I just lucky with the port numbers? "setsebool -P nis_enabled 1" did make it go away with Fedora 33.
It is present on Fedora 34. Related: bug #1963065 I saw following while testing webrtc in Firefox: ***** Plugin catchall (1.41 confidence) suggests ************************** If you believe that rpcbind should be allowed name_bind access on the port 65007 udp_socket by default. Then you should report this as a bug. Additional Information: Source Context system_u:system_r:rpcbind_t:s0 Target Context system_u:object_r:unreserved_port_t:s0 Target Objects port 65007 [ udp_socket ] Source rpcbind Source Path rpcbind Port 65007 SELinux Policy RPM selinux-policy-targeted-34.14-1.fc34.noarch Local Policy RPM selinux-policy-targeted-34.14-1.fc34.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Raw Audit Messages type=AVC msg=audit(1628548964.684:585): avc: denied { name_bind } for pid=15853 comm="rpcbind" src=65007 scontext=system_u:system_r:rpcbind_t:s0 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=udp_socket permissive=1 Hash: rpcbind,rpcbind_t,unreserved_port_t,udp_socket,name_bind
Per the previous comment, can somebody with permission please update the Version: field? TiA.
*** Bug 2049300 has been marked as a duplicate of this bug. ***
It stopped happening a while ago so, I'm closing this.
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
We still see this problem on Fedora 36.
Also seeing this bug on Fedora 36. Using "setsebool -P nis_enabled 1" seems to change the behaviour of nfs but not fix it.
Confirmed on current Fedora 37 as well. E.g. https://cockpit-logs.us-east-1.linodeobjects.com/pull-17690-20220831-093050-40773f60-fedora-37-bots-3801/log.html#171
Just updated to FC36. This time I decided to try eliminate it (I can't recall when it first appeared on my system, but very long ago, since some FC2x) and I got to this bug report. Tried to do 'setsebool -P nis_enabled 1' with the following output: # setsebool -P nis_enabled 1 libsepol.context_from_record: type stalld_var_run_t is not defined libsepol.context_from_record: could not create context structure libsepol.context_from_string: could not create context structure libsepol.sepol_context_to_sid: could not convert system_u:object_r:stalld_var_run_t:s0 to sid invalid context system_u:object_r:stalld_var_run_t:s0 Failed to commit changes to booleans: Success #
*** Bug 1983604 has been marked as a duplicate of this bug. ***
*** Bug 2154609 has been marked as a duplicate of this bug. ***
Kicking the can down the road... This still happens on Fedora 38. https://cockpit-logs.us-east-1.linodeobjects.com/pull-4412-20230215-173047-faf4e3ec-fedora-38-cockpit-project-cockpit-machines/log.html#80
Similar problem has been detected: this happens after mounting an NFS share hashmarkername: setroubleshoot kernel: 6.1.12-200.fc37.x86_64 package: selinux-policy-targeted-37.19-1.fc37.noarch reason: SELinux is preventing rpcbind from 'name_bind' accesses on the udp_socket port 61140. type: libreport
Similar problem has been detected: no idea what caused it but it happened during regular dnf update hashmarkername: setroubleshoot kernel: 6.1.14-200.fc37.x86_64 package: selinux-policy-targeted-37.19-1.fc37.noarch reason: SELinux is preventing rpcbind from 'name_bind' accesses on the udp_socket port 62152. type: libreport
Fedora 38 when NFS Client is started Similar problem has been detected: no idea what caused it but it happened during regular dnf update hashmarkername: setroubleshoot kernel: 6.1.14-200.fc37.x86_64 package: selinux-policy-targeted-37.19-1.fc37.noarch reason: SELinux is preventing rpcbind from 'name_bind' accesses on the udp_socket port 62152. type: libreport
the problem still happens on Rawhide... rpcbind-1.2.6-4.rc2.fc39.1.x86_64 SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: permissive Mode from config file: permissive Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 33 selinux-policy-38.29-1.fc40.noarch ---- time->Tue Oct 3 17:56:11 2023 type=AVC msg=audit(1696370171.456:925): avc: denied { name_bind } for pid=636825 comm="rpcbind" src=63032 scontext=system_u:system_r:rpcbind_t:s0 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=udp_socket permissive=1
*** Bug 2231613 has been marked as a duplicate of this bug. ***
Cockpit's OS bug tracker [1] hasn't seen this in about two months, so this either got fixed, or NFS has stopped trying this operation? [1] https://github.com/cockpit-project/bots/issues/118
*** Bug 2272391 has been marked as a duplicate of this bug. ***
*** Bug 2273372 has been marked as a duplicate of this bug. ***
This ticket needs Version: updating to 39 as this happened there for me. Can somebody with permission to do that please do it?
*** Bug 2274603 has been marked as a duplicate of this bug. ***
*** Bug 2291441 has been marked as a duplicate of this bug. ***
And seeing the issue in F-40 as well ...
*** Bug 2294178 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora Linux 40 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 40 on 2025-05-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '40'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 40 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.