Description of problem: SELinux is preventing readlink from 'read' accesses on the lnk_file virbr0. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that readlink should be allowed read access on the virbr0 lnk_file 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 'readlink' --raw | audit2allow -M my-readlink # semodule -X 300 -i my-readlink.pp Additional Information: Source Context system_u:system_r:NetworkManager_dispatcher_t:s0 Target Context system_u:object_r:sysfs_t:s0 Target Objects virbr0 [ lnk_file ] Source readlink Source Path readlink Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-36.5-1.fc36.noarch Local Policy RPM selinux-policy-targeted-36.5-1.fc36.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 5.16.16-200.fc35.x86_64 #1 SMP PREEMPT Wed Mar 23 00:44:58 CET 2022 x86_64 x86_64 Alert Count 3 First Seen 2022-04-05 23:55:58 CEST Last Seen 2022-04-05 23:55:59 CEST Local ID 2268743f-735c-4213-a88f-46cb05ad2c61 Raw Audit Messages type=AVC msg=audit(1649195759.77:395): avc: denied { read } for pid=2525 comm="readlink" name="virbr0" dev="sysfs" ino=48505 scontext=system_u:system_r:NetworkManager_dispatcher_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=lnk_file permissive=1 Hash: readlink,NetworkManager_dispatcher_t,sysfs_t,lnk_file,read Version-Release number of selected component: selinux-policy-targeted-36.5-1.fc36.noarch Additional info: component: selinux-policy reporter: libreport-2.17.1 hashmarkername: setroubleshoot kernel: 5.16.16-200.fc35.x86_64 type: libreport
Michael, Do you know which nm-disp plugin triggers this denial? Can you list all your installed plugins? ls -lRZ /etc/NetworkManager/dispatcher.d/ /usr/lib/NetworkManager/dispatcher.d/
Hi, below you can find the output of the requested command. I'm not entirely sure, what exactly triggered the denial but I have one suspicion, which is tlp-rdw. Reason therefore is that I also saw another problem in that area (https://bugzilla.redhat.com/show_bug.cgi?id=2070329) Kind regards, Michael ls -lRZ /etc/NetworkManager/dispatcher.d/ /usr/lib/NetworkManager/dispatcher.d/ /etc/NetworkManager/dispatcher.d/: total 0 drwxr-xr-x. 1 root root system_u:object_r:NetworkManager_dispatcher_script_t:s0 0 Apr 7 14:06 no-wait.d drwxr-xr-x. 1 root root system_u:object_r:NetworkManager_dispatcher_script_t:s0 0 Apr 7 14:06 pre-down.d drwxr-xr-x. 1 root root system_u:object_r:NetworkManager_dispatcher_script_t:s0 0 Apr 7 14:06 pre-up.d /etc/NetworkManager/dispatcher.d/no-wait.d: total 0 /etc/NetworkManager/dispatcher.d/pre-down.d: total 0 /etc/NetworkManager/dispatcher.d/pre-up.d: total 0 /usr/lib/NetworkManager/dispatcher.d/: total 24 -rwxr-xr-x. 1 root root system_u:object_r:NetworkManager_dispatcher_iscsid_script_t:s0 104 Jan 20 14:32 04-iscsi -rwxr-xr-x. 1 root root system_u:object_r:NetworkManager_dispatcher_dhclient_script_t:s0 1066 Jan 20 01:39 11-dhclient -rwxr-xr-x. 1 root root system_u:object_r:NetworkManager_dispatcher_chronyc_script_t:s0 1497 Feb 16 11:04 20-chrony-dhcp -rwxr-xr-x. 1 root root system_u:object_r:NetworkManager_dispatcher_chronyc_script_t:s0 627 Feb 16 11:04 20-chrony-onoffline -rwxr-xr-x. 1 root root system_u:object_r:NetworkManager_dispatcher_script_t:s0 5653 Jan 22 04:00 99tlp-rdw-nm drwxr-xr-x. 1 root root system_u:object_r:NetworkManager_dispatcher_script_t:s0 0 Apr 7 14:06 no-wait.d drwxr-xr-x. 1 root root system_u:object_r:NetworkManager_dispatcher_script_t:s0 0 Apr 7 14:06 pre-down.d drwxr-xr-x. 1 root root system_u:object_r:NetworkManager_dispatcher_script_t:s0 0 Apr 7 14:06 pre-up.d /usr/lib/NetworkManager/dispatcher.d/no-wait.d: total 0 /usr/lib/NetworkManager/dispatcher.d/pre-down.d: total 0 /usr/lib/NetworkManager/dispatcher.d/pre-up.d: total 0
I also think it is tlp-rdw as this is the only script with the NetworkManager_dispatcher_script_t type. Let's continue in the other bz. *** This bug has been marked as a duplicate of bug 2070329 ***