Bug 2093155

Summary: SELinux is preventing logger from 'create' accesses on the unix_dgram_socket labeled NetworkManager_dispatcher_custom_t.
Product: [Fedora] Fedora Reporter: Berend De Schouwer <berend>
Component: selinux-policyAssignee: Zdenek Pytela <zpytela>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 36CC: arun.neelicattu, ddelcian, dwalsh, grepl.miroslav, lvrabec, mmalik, omosnace, pkoncity, ssitani, vmojzis, zpytela
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:d85d3cb2ec16ef290b5b249ad6dce4a532ca572a45aa019fd3c0d18de1ca0209;VARIANT_ID=workstation;
Fixed In Version: selinux-policy-36.13-3.fc36 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-08-05 01:34:36 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Berend De Schouwer 2022-06-03 06:37:59 UTC
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

Comment 1 Daniel Del Ciancio 2022-06-10 14:11:07 UTC
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!

Comment 5 Zdenek Pytela 2022-06-10 19:38:49 UTC
(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

Comment 6 Daniel Del Ciancio 2022-06-13 14:04:47 UTC
(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?

Comment 7 Zdenek Pytela 2022-06-13 15:29:53 UTC
(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.

Comment 8 Zdenek Pytela 2022-06-28 15:28:04 UTC
*** Bug 2101866 has been marked as a duplicate of this bug. ***

Comment 9 Fedora Update System 2022-06-30 07:25:50 UTC
FEDORA-2022-fd22b79a84 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-fd22b79a84

Comment 10 Zdenek Pytela 2022-06-30 11:34:14 UTC
*** Bug 2100562 has been marked as a duplicate of this bug. ***

Comment 11 Fedora Update System 2022-07-01 02:09:49 UTC
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.

Comment 12 Fedora Update System 2022-07-16 01:12:48 UTC
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.

Comment 13 Fedora Update System 2022-08-04 02:41:51 UTC
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.

Comment 14 Fedora Update System 2022-08-05 01:34:36 UTC
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.