Description of problem: SELinux is preventing logger from 'create' accesses on the unix_dgram_socket labeled NetworkManager_dispatcher_custom_t. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that logger should be allowed create access on unix_dgram_socket labeled NetworkManager_dispatcher_custom_t 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 'logger' --raw | audit2allow -M my-logger # semodule -X 300 -i my-logger.pp Additional Information: Source Context system_u:system_r:NetworkManager_dispatcher_custom _t:s0 Target Context system_u:system_r:NetworkManager_dispatcher_custom _t:s0 Target Objects Unknown [ unix_dgram_socket ] Source logger Source Path logger Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-36.9-1.fc36.noarch Local Policy RPM selinux-policy-targeted-36.9-1.fc36.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 5.17.8-300.fc36.x86_64 #1 SMP PREEMPT Mon May 16 01:00:37 UTC 2022 x86_64 x86_64 Alert Count 16 First Seen 2022-06-01 02:12:13 SAST Last Seen 2022-06-03 08:36:01 SAST Local ID fde548aa-aadb-4c0a-a761-b4da9e46af79 Raw Audit Messages type=AVC msg=audit(1654238161.81:4923): avc: denied { create } for pid=696389 comm="logger" scontext=system_u:system_r:NetworkManager_dispatcher_custom_t:s0 tcontext=system_u:system_r:NetworkManager_dispatcher_custom_t:s0 tclass=unix_dgram_socket permissive=1 Hash: logger,NetworkManager_dispatcher_custom_t,NetworkManager_dispatcher_custom_t,unix_dgram_socket,create Version-Release number of selected component: selinux-policy-targeted-36.9-1.fc36.noarch Additional info: component: selinux-policy reporter: libreport-2.17.1 hashmarkername: setroubleshoot kernel: 5.17.8-300.fc36.x86_64 type: libreport
Hello, To add to this, I've using my own custom nm dispatcher script (which worked fine prior to Fedora 36) and now I'm getting a lot of AVCs from my script. I have attached three files : 1) Raw AVC audit entries (my-custom-raw.txt) 2) Text version of policy generated (my-custom.te) 3) Binary version of policy generated (my-custom.pp) Any reason why a new domain called NetworkManager_dispatcher_custom_t is being created for a custom dispatcher script (in my case, for 99-post-vpn.sh)? Should scripts found in /etc/NetworkManager/dispatcher.d/ not inherit the default domain (NetworkManager_dispatcher_script_t) defined for files falling under that sub-directory? The selinux permissions for the /etc/NetworkManager path is: -rw-r--r--. 1 root root system_u:object_r:NetworkManager_etc_rw_t:s0 2206 Nov 16 2021 /etc/NetworkManager/NetworkManager.conf -rw-r--r--. 1 root root system_u:object_r:NetworkManager_etc_t:s0 2263 Oct 29 2021 /etc/NetworkManager/NetworkManager.conf.rpmnew drwxr-xr-x. 2 root root system_u:object_r:NetworkManager_etc_t:s0 4096 May 30 08:27 /etc/NetworkManager/conf.d drwxr-xr-x. 5 root root system_u:object_r:NetworkManager_dispatcher_script_t:s0 4096 Jun 10 09:51 /etc/NetworkManager/dispatcher.d drwxr-xr-x. 2 root root system_u:object_r:NetworkManager_etc_t:s0 4096 May 30 08:27 /etc/NetworkManager/dnsmasq-shared.d drwxr-xr-x. 2 root root system_u:object_r:NetworkManager_etc_t:s0 4096 May 30 08:27 /etc/NetworkManager/dnsmasq.d drwxr-xr-x. 2 root root system_u:object_r:NetworkManager_etc_rw_t:s0 4096 Jun 10 09:53 /etc/NetworkManager/system-connections /etc/NetworkManager/dispatcher.d/: total 20 -rwxr-xr-x. 1 root root system_u:object_r:NetworkManager_dispatcher_script_t:s0 439 Jun 10 04:02 15-resolv.sh -rwxr-xr-x. 1 root root system_u:object_r:NetworkManager_dispatcher_script_t:s0 883 Jun 10 09:51 99-post-vpn.sh drwxr-xr-x. 2 root root system_u:object_r:NetworkManager_dispatcher_script_t:s0 4096 May 30 08:27 no-wait.d drwxr-xr-x. 2 root root system_u:object_r:NetworkManager_dispatcher_script_t:s0 4096 May 30 08:27 pre-down.d drwxr-xr-x. 2 root root system_u:object_r:NetworkManager_dispatcher_script_t:s0 4096 May 30 08:27 pre-up.d Thanks!
(In reply to Daniel Del Ciancio from comment #1) > Hello, > > To add to this, I've using my own custom nm dispatcher script (which worked > fine prior to Fedora 36) and now I'm getting a lot of AVCs from my script. > I have attached three files : > 1) Raw AVC audit entries (my-custom-raw.txt) > 2) Text version of policy generated (my-custom.te) > 3) Binary version of policy generated (my-custom.pp) Thank you for the data, I will analyze them. You can notice the permissive=1 entry which means all the permissions were allowed, but audited. It is a temporary setting. The results can be used both as general updates in selinux-policy and as an opportunity to review the system state, e. g. why dac_read search is required. type=AVC msg=audit(1654837936.708:1038): avc: denied { dac_read_search } for pid=30036 comm="99-post-vpn.sh" capability=2 scontext=system_u:system_r:NetworkManager_dispatcher_custom_t:s0 tcontext=system_u:system_r:NetworkManager_dispatcher_custom_t:s0 tclass=capability permissive=1 > > Any reason why a new domain called NetworkManager_dispatcher_custom_t is > being created for a custom dispatcher script (in my case, for > 99-post-vpn.sh)? This is by design. > > Should scripts found in /etc/NetworkManager/dispatcher.d/ not inherit the > default domain (NetworkManager_dispatcher_script_t) defined for files > falling under that sub-directory? > > The selinux permissions for the /etc/NetworkManager path is: > > -rw-r--r--. 1 root root system_u:object_r:NetworkManager_etc_rw_t:s0 > 2206 Nov 16 2021 /etc/NetworkManager/NetworkManager.conf > -rw-r--r--. 1 root root system_u:object_r:NetworkManager_etc_t:s0 > 2263 Oct 29 2021 /etc/NetworkManager/NetworkManager.conf.rpmnew > drwxr-xr-x. 2 root root system_u:object_r:NetworkManager_etc_t:s0 > 4096 May 30 08:27 /etc/NetworkManager/conf.d > drwxr-xr-x. 5 root root > system_u:object_r:NetworkManager_dispatcher_script_t:s0 4096 Jun 10 09:51 > /etc/NetworkManager/dispatcher.d > drwxr-xr-x. 2 root root system_u:object_r:NetworkManager_etc_t:s0 > 4096 May 30 08:27 /etc/NetworkManager/dnsmasq-shared.d > drwxr-xr-x. 2 root root system_u:object_r:NetworkManager_etc_t:s0 > 4096 May 30 08:27 /etc/NetworkManager/dnsmasq.d > drwxr-xr-x. 2 root root system_u:object_r:NetworkManager_etc_rw_t:s0 > 4096 Jun 10 09:53 /etc/NetworkManager/system-connections > > /etc/NetworkManager/dispatcher.d/: > total 20 > -rwxr-xr-x. 1 root root > system_u:object_r:NetworkManager_dispatcher_script_t:s0 439 Jun 10 04:02 > 15-resolv.sh > -rwxr-xr-x. 1 root root > system_u:object_r:NetworkManager_dispatcher_script_t:s0 883 Jun 10 09:51 > 99-post-vpn.sh > drwxr-xr-x. 2 root root > system_u:object_r:NetworkManager_dispatcher_script_t:s0 4096 May 30 08:27 > no-wait.d > drwxr-xr-x. 2 root root > system_u:object_r:NetworkManager_dispatcher_script_t:s0 4096 May 30 08:27 > pre-down.d > drwxr-xr-x. 2 root root > system_u:object_r:NetworkManager_dispatcher_script_t:s0 4096 May 30 08:27 > pre-up.d This output seems to be correct. You can check with # restorecon -Rvn /etc/NetworkManager
(In reply to Zdenek Pytela from comment #5) > (In reply to Daniel Del Ciancio from comment #1) > > Hello, > > > > To add to this, I've using my own custom nm dispatcher script (which worked > > fine prior to Fedora 36) and now I'm getting a lot of AVCs from my script. > > I have attached three files : > > 1) Raw AVC audit entries (my-custom-raw.txt) > > 2) Text version of policy generated (my-custom.te) > > 3) Binary version of policy generated (my-custom.pp) > Thank you for the data, I will analyze them. You can notice the permissive=1 > entry which means all the permissions were allowed, but audited. It is a > temporary setting. The results can be used both as general updates in > selinux-policy and as an opportunity to review the system state, e. g. why > dac_read search is required. > > type=AVC msg=audit(1654837936.708:1038): avc: denied { dac_read_search } > for pid=30036 comm="99-post-vpn.sh" capability=2 > scontext=system_u:system_r:NetworkManager_dispatcher_custom_t:s0 > tcontext=system_u:system_r:NetworkManager_dispatcher_custom_t:s0 > tclass=capability permissive=1 > > > > > Any reason why a new domain called NetworkManager_dispatcher_custom_t is > > being created for a custom dispatcher script (in my case, for > > 99-post-vpn.sh)? > This is by design. > > > > > Should scripts found in /etc/NetworkManager/dispatcher.d/ not inherit the > > default domain (NetworkManager_dispatcher_script_t) defined for files > > falling under that sub-directory? > > > > The selinux permissions for the /etc/NetworkManager path is: > > > > -rw-r--r--. 1 root root system_u:object_r:NetworkManager_etc_rw_t:s0 > > 2206 Nov 16 2021 /etc/NetworkManager/NetworkManager.conf > > -rw-r--r--. 1 root root system_u:object_r:NetworkManager_etc_t:s0 > > 2263 Oct 29 2021 /etc/NetworkManager/NetworkManager.conf.rpmnew > > drwxr-xr-x. 2 root root system_u:object_r:NetworkManager_etc_t:s0 > > 4096 May 30 08:27 /etc/NetworkManager/conf.d > > drwxr-xr-x. 5 root root > > system_u:object_r:NetworkManager_dispatcher_script_t:s0 4096 Jun 10 09:51 > > /etc/NetworkManager/dispatcher.d > > drwxr-xr-x. 2 root root system_u:object_r:NetworkManager_etc_t:s0 > > 4096 May 30 08:27 /etc/NetworkManager/dnsmasq-shared.d > > drwxr-xr-x. 2 root root system_u:object_r:NetworkManager_etc_t:s0 > > 4096 May 30 08:27 /etc/NetworkManager/dnsmasq.d > > drwxr-xr-x. 2 root root system_u:object_r:NetworkManager_etc_rw_t:s0 > > 4096 Jun 10 09:53 /etc/NetworkManager/system-connections > > > > /etc/NetworkManager/dispatcher.d/: > > total 20 > > -rwxr-xr-x. 1 root root > > system_u:object_r:NetworkManager_dispatcher_script_t:s0 439 Jun 10 04:02 > > 15-resolv.sh > > -rwxr-xr-x. 1 root root > > system_u:object_r:NetworkManager_dispatcher_script_t:s0 883 Jun 10 09:51 > > 99-post-vpn.sh > > drwxr-xr-x. 2 root root > > system_u:object_r:NetworkManager_dispatcher_script_t:s0 4096 May 30 08:27 > > no-wait.d > > drwxr-xr-x. 2 root root > > system_u:object_r:NetworkManager_dispatcher_script_t:s0 4096 May 30 08:27 > > pre-down.d > > drwxr-xr-x. 2 root root > > system_u:object_r:NetworkManager_dispatcher_script_t:s0 4096 May 30 08:27 > > pre-up.d > This output seems to be correct. You can check with > > # restorecon -Rvn /etc/NetworkManager No selinux labels were modified using the above command. Also, if the NetworkManager_dispatcher_custom_t is new by design, why not have some fcontext policies that could allow permissions for it? Both scripts are labeled with NetworkManager_dispatcher_script_t, any reason why this domain isn't being used instead of NetworkManager_dispatcher_custom_t?
(In reply to Daniel Del Ciancio from comment #6) > > This output seems to be correct. You can check with > > > > # restorecon -Rvn /etc/NetworkManager > > No selinux labels were modified using the above command. With the -n switch the changes are only reported. > Also, if the NetworkManager_dispatcher_custom_t is new by design, why not > have some fcontext policies that could allow permissions for it? This is the current state, common permissions (e. g. execute ifconfig) are allowed, the rest is allowed+audited. It will change soon to not audit them. > > Both scripts are labeled with NetworkManager_dispatcher_script_t, any reason > why this domain isn't being used instead of > NetworkManager_dispatcher_custom_t? Different types are used for executables and for processes.
*** Bug 2101866 has been marked as a duplicate of this bug. ***
FEDORA-2022-fd22b79a84 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-fd22b79a84
*** Bug 2100562 has been marked as a duplicate of this bug. ***
FEDORA-2022-fd22b79a84 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-fd22b79a84` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-fd22b79a84 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-320775eb9a has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-320775eb9a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-320775eb9a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-139ec288ca has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-139ec288ca` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-139ec288ca See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-139ec288ca has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.