Bug 1956290 - SELinux is preventing gmain from 'watch' access to various filesystem and font dirs
Summary: SELinux is preventing gmain from 'watch' access to various filesystem and fon...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 34
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-05-03 11:58 UTC by Timo Trinks
Modified: 2022-02-17 03:15 UTC (History)
9 users (show)

Fixed In Version: selinux-policy-35.15-1.fc35
Clone Of:
Environment:
Last Closed: 2022-02-17 03:15:01 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Timo Trinks 2021-05-03 11:58:25 UTC
Description of problem:

After upgrading Fedora from 33 to 34 executing Firefox within SELinux sandbox (e.g. sandbox -X -t sandbox_net_t -t sandbox_web_t -w 1280x1024 firefox) triggers several "gmain was denied watch" errors for "/usr/share/fonts", "/etc/fonts/conf.d" and "/usr/local/share":

<snip>

SELinux is preventing gmain from watch access on the directory /usr/share/fonts.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that gmain should be allowed watch access on the fonts directory 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 'gmain' --raw | audit2allow -M my-gmain
# semodule -X 300 -i my-gmain.pp

Additional Information:
Source Context                unconfined_u:unconfined_r:sandbox_web_client_t:s0:
                              c104,c937
Target Context                system_u:object_r:fonts_t:s0
Target Objects                /usr/share/fonts [ dir ]
Source                        gmain
Source Path                   gmain
Port                          <Unknown>
Host                          <redacted>
Source RPM Packages
Target RPM Packages           fonts-filesystem-2.0.5-5.fc34.noarch
SELinux Policy RPM            selinux-policy-targeted-34.4-1.fc34.noarch
Local Policy RPM              selinux-policy-targeted-34.4-1.fc34.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     <redacted>
Platform                      Linux <redacted>
                              5.11.17-300.fc34.x86_64 #1 SMP Wed Apr 28 14:21:28
                              UTC 2021 x86_64 x86_64
Alert Count                   264
First Seen                    2021-05-03 21:01:20 UTC
Last Seen                     2021-05-03 21:01:40 UTC
Local ID                      <redacted>

Raw Audit Messages
type=AVC msg=audit(1620039700.516:3217): avc:  denied  { watch } for  pid=17187 comm="gmain" path="/usr/share/fonts" dev="dm-6" ino=16777351 scontext=unconfined_u:unconfined_r:sandbox_web_client_t:s0:c104,c937 tcontext=system_u:object_r:fonts_t:s0 tclass=dir permissive=0


Hash: gmain,sandbox_web_client_t,fonts_t,dir,watch

<snap>

<snip>

SELinux is preventing gmain from watch access on the directory /etc/fonts/conf.d.

*****  Plugin catchall_labels (83.8 confidence) suggests   *******************

If you want to allow gmain to have watch access on the conf.d directory
Then you need to change the label on /etc/fonts/conf.d
Do
# semanage fcontext -a -t FILE_TYPE '/etc/fonts/conf.d'
where FILE_TYPE is one of the following: mozilla_plugin_rw_t, sandbox_file_t.
Then execute:
restorecon -v '/etc/fonts/conf.d'


*****  Plugin catchall (17.1 confidence) suggests   **************************

If you believe that gmain should be allowed watch access on the conf.d directory 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 'gmain' --raw | audit2allow -M my-gmain
# semodule -X 300 -i my-gmain.pp

Additional Information:
Source Context                unconfined_u:unconfined_r:sandbox_web_client_t:s0:
                              c104,c937
Target Context                system_u:object_r:etc_t:s0
Target Objects                /etc/fonts/conf.d [ dir ]
Source                        gmain
Source Path                   gmain
Port                          <Unknown>
Host                          <redacted>
Source RPM Packages
Target RPM Packages           fonts-filesystem-2.0.5-5.fc34.noarch
SELinux Policy RPM            selinux-policy-targeted-34.4-1.fc34.noarch
Local Policy RPM              selinux-policy-targeted-34.4-1.fc34.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     <redacted>
Platform                      Linux <redacted>
                              5.11.17-300.fc34.x86_64 #1 SMP Wed Apr 28 14:21:28
                              UTC 2021 x86_64 x86_64
Alert Count                   509
First Seen                    2021-05-03 21:01:16 UTC
Last Seen                     2021-05-03 21:01:44 UTC
Local ID                      <redacted>

Raw Audit Messages
type=AVC msg=audit(1620039704.513:3363): avc:  denied  { watch } for  pid=17187 comm="gmain" path="/etc/fonts/conf.d" dev="dm-4" ino=33575043 scontext=unconfined_u:unconfined_r:sandbox_web_client_t:s0:c104,c937 tcontext=system_u:object_r:etc_t:s0 tclass=dir permissive=0


Hash: gmain,sandbox_web_client_t,etc_t,dir,watch

<snap>

<snip>

SELinux is preventing gmain from watch access on the directory /usr/local/share.

*****  Plugin catchall_labels (83.8 confidence) suggests   *******************

If you want to allow gmain to have watch access on the share directory
Then you need to change the label on /usr/local/share
Do
# semanage fcontext -a -t FILE_TYPE '/usr/local/share'
where FILE_TYPE is one of the following: mozilla_plugin_rw_t, sandbox_file_t.
Then execute:
restorecon -v '/usr/local/share'


*****  Plugin catchall (17.1 confidence) suggests   **************************

If you believe that gmain should be allowed watch access on the share directory 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 'gmain' --raw | audit2allow -M my-gmain
# semodule -X 300 -i my-gmain.pp

Additional Information:
Source Context                unconfined_u:unconfined_r:sandbox_web_client_t:s0:
                              c104,c937
Target Context                system_u:object_r:usr_t:s0
Target Objects                /usr/local/share [ dir ]
Source                        gmain
Source Path                   gmain
Port                          <Unknown>
Host                          <redacted>
Source RPM Packages
Target RPM Packages           filesystem-3.14-5.fc34.x86_64
SELinux Policy RPM            selinux-policy-targeted-34.4-1.fc34.noarch
Local Policy RPM              selinux-policy-targeted-34.4-1.fc34.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     <redacted>
Platform                      Linux <redacted>
                              5.11.17-300.fc34.x86_64 #1 SMP Wed Apr 28 14:21:28
                              UTC 2021 x86_64 x86_64
Alert Count                   8
First Seen                    2021-05-03 21:01:20 UTC
Last Seen                     2021-05-03 21:01:48 UTC
Local ID                      <redacted>

Raw Audit Messages
type=AVC msg=audit(1620039708.516:3462): avc:  denied  { watch } for  pid=17187 comm="gmain" path="/usr/local/share" dev="dm-6" ino=33902600 scontext=unconfined_u:unconfined_r:sandbox_web_client_t:s0:c104,c937 tcontext=system_u:object_r:usr_t:s0 tclass=dir permissive=0


Hash: gmain,sandbox_web_client_t,usr_t,dir,watch

<snap>


Version-Release number of selected component (if applicable):

selinux-policy-targeted-34.4-1.fc34.noarch

How reproducible:

Always.

Steps to Reproduce:
1. sandbox -X -t sandbox_net_t -t sandbox_web_t -w 1280x1024 firefox
2.
3.

Actual results:


Expected results:

Run Firefox within SELinux sandbox without several hundreds of SELinux security alerts.

Additional info:

Comment 1 Timo Trinks 2021-07-04 04:53:09 UTC
This expands to dir "etc/fonts/conf.d" and "xdg-desktop-por":

<snip>

<redacted> setroubleshoot[17843]: SELinux is preventing xdg-desktop-por from watch access on the directory /etc/fonts/conf.d.
                                                             
                                  *****  Plugin catchall_labels (83.8 confidence) suggests   *******************
                                                                                        
                                  If you want to allow xdg-desktop-por to have watch access on the conf.d directory
                                  Then you need to change the label on /etc/fonts/conf.d
                                  Do
                                  # semanage fcontext -a -t FILE_TYPE '/etc/fonts/conf.d'
                                  where FILE_TYPE is one of the following: mozilla_plugin_rw_t, sandbox_file_t.
                                  Then execute:
                                  restorecon -v '/etc/fonts/conf.d'
                                                             
                                                             
                                  *****  Plugin catchall (17.1 confidence) suggests   **************************
                                  
                                  If you believe that xdg-desktop-por should be allowed watch access on the conf.d directory 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 'xdg-desktop-por' --raw | audit2allow -M my-xdgdesktoppor
                                  # semodule -X 300 -i my-xdgdesktoppor.pp

<snap>

Comment 2 Zdenek Pytela 2022-02-11 17:15:02 UTC
I've submitted a Fedora PR to address the issue:
https://github.com/fedora-selinux/selinux-policy/pull/1070

Comment 3 Fedora Update System 2022-02-15 14:58:03 UTC
FEDORA-2022-aa5df3a7eb has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-aa5df3a7eb

Comment 4 Fedora Update System 2022-02-16 01:50:48 UTC
FEDORA-2022-aa5df3a7eb has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-aa5df3a7eb`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-aa5df3a7eb

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 5 Fedora Update System 2022-02-17 03:15:01 UTC
FEDORA-2022-aa5df3a7eb has been pushed to the Fedora 35 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.