Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 2093155 - SELinux is preventing logger from 'create' accesses on the unix_dgram_socket labeled NetworkManager_dispatcher_custom_t.
Summary: SELinux is preventing logger from 'create' accesses on the unix_dgram_socket ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 36
Hardware: x86_64
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:d85d3cb2ec16ef290b5b249ad6d...
: 2100562 2101866 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-06-03 06:37 UTC by Berend De Schouwer
Modified: 2022-08-05 01:34 UTC (History)
11 users (show)

Fixed In Version: selinux-policy-36.13-3.fc36
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-08-05 01:34:36 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github fedora-selinux selinux-policy pull 1230 0 None open Allow nm-dispatcher custom plugin create and use unix dgram socket 2022-06-10 19:38:49 UTC

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.


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