RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1775975 - SELinux is preventing /usr/libexec/platform-python3.6 from read access on the file virt.module
Summary: SELinux is preventing /usr/libexec/platform-python3.6 from read access on the...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: anaconda
Version: 8.1
Hardware: noarch
OS: Linux
medium
medium
Target Milestone: rc
: 8.3
Assignee: Vladimír Slávik
QA Contact: Release Test Team
bilhar
URL:
Whiteboard:
: 1753377 1844765 1882974 (view as bug list)
Depends On:
Blocks: 1825061
TreeView+ depends on / blocked
 
Reported: 2019-11-24 07:20 UTC by Joachim Frieben
Modified: 2024-03-25 15:32 UTC (History)
30 users (show)

Fixed In Version: anaconda-33.16.3.5-1
Doc Type: Bug Fix
Doc Text:
.SELinux contexts are now set correctly Previously, when SELinux was in enforcing mode, incorrect SELinux contexts on some folders and files resulted in unexpected AVC denials when attempting to access these files after installation. With this update, Anaconda sets the correct SELinux contexts. As a result, you can now access the folders and files without manually relabeling the filesystem.
Clone Of:
Environment:
Last Closed: 2020-11-04 03:22:54 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:4729 0 None None None 2020-11-04 03:23:13 UTC

Description Joachim Frieben 2019-11-24 07:20:45 UTC 
SELinux is preventing /usr/libexec/platform-python3.6 from read access on the file virt.module.

*****  Plugin catchall_boolean (89.3 confidence) suggests   ******************

If you want to allow daemons to dump core
Then you must tell SELinux about this by enabling the 'daemons_dump_core' boolean.

Do
setsebool -P daemons_dump_core 1

*****  Plugin catchall (11.6 confidence) suggests   **************************

If you believe that platform-python3.6 should be allowed read access on the virt.module 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 'rhsmcertd-worke' --raw | audit2allow -M my-rhsmcertdworke
# semodule -X 300 -i my-rhsmcertdworke.pp

Additional Information:
Source Context                system_u:system_r:rhsmcertd_t:s0
Target Context                system_u:object_r:root_t:s0
Target Objects                virt.module [ file ]
Source                        rhsmcertd-worke
Source Path                   /usr/libexec/platform-python3.6
Port                          <Unknown>
Host                          noname
Source RPM Packages           platform-python-3.6.8-15.1.el8.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.14.3-20.el8.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     noname
Platform                      Linux noname 4.18.0-147.0.3.el8_1.x86_64 #1 SMP
                              Mon Nov 11 12:58:36 UTC 2019 x86_64 x86_64
Alert Count                   4
First Seen                    2019-11-24 08:14:53 CET
Last Seen                     2019-11-24 08:14:53 CET
Local ID                      4e4324d2-6198-4962-ae90-01dd1ec44f96

Raw Audit Messages
type=AVC msg=audit(1574579693.397:137): avc:  denied  { read } for  pid=6927 comm="rhsmcertd-worke" name="virt.module" dev="dm-1" ino=16797830 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=file permissive=0


type=SYSCALL msg=audit(1574579693.397:137): arch=x86_64 syscall=openat success=no exit=EACCES a0=ffffff9c a1=562d73218cf0 a2=0 a3=0 items=0 ppid=3197 pid=6927 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=rhsmcertd-worke exe=/usr/libexec/platform-python3.6 subj=system_u:system_r:rhsmcertd_t:s0 key=(null)

Hash: rhsmcertd-worke,rhsmcertd_t,root_t,file,read
Comment 1 Lukas Vrabec 2019-11-25 09:59:14 UTC 
Hi Joachim, 

Do you know where is file "virt.module" located? 

Thanks,
Lukas.
Comment 2 Marcus West 2019-11-28 03:51:10 UTC 
I am seeing this as well on my system, location appears to be /etc/dnf/modules.d/virt.module

Other similar errors:

Nov 28 10:48:38 hostname platform-python[23478]: SELinux is preventing /usr/libexec/platform-python3.6 from read access on the file /etc/dnf/modules.d/javapackages-runtime.module.
Nov 28 10:48:41 hostname platform-python[23478]: SELinux is preventing /usr/libexec/platform-python3.6 from read access on the file /etc/dnf/modules.d/llvm-toolset.module.
Nov 28 10:48:54 hostname platform-python[23511]: SELinux is preventing /usr/libexec/platform-python3.6 from read access on the file /etc/dnf/modules.d/python36.module.
Nov 28 10:49:07 hostname platform-python[23530]: SELinux is preventing /usr/libexec/platform-python3.6 from read access on the file /etc/dnf/modules.d/satellite-5-client.module.
Nov 28 10:49:20 hostname platform-python[23636]: SELinux is preventing /usr/libexec/platform-python3.6 from read access on the file /etc/dnf/modules.d/virt.module.

This happens twice a day at non-regular times.
Comment 3 Lukas Vrabec 2019-11-28 10:05:23 UTC 
Hi Dan, 

I think we saw this in past. Again I believe this is bad labeling in  /etc/dnf/modules.d directory.
Comment 4 Marcus West 2019-11-28 23:12:16 UTC 
I fixed SELinux labels on those files (restorecon) and the problem has gone away.

I updated back on Nov 6 and the problem started after that.  There were 671 packages altered so not sure which one caused it...  These files are not owned by any rpm.  After update I initially saw this:

Nov 11 10:23:30 hostname setroubleshoot[12788]: failed to retrieve rpm info for /etc/dnf/modules.d/javapackages-runtime.module
Nov 11 10:23:30 hostname setroubleshoot[12788]: SELinux is preventing /usr/libexec/platform-python3.6 from read access on the file /etc/dnf/modules.d/javapackages-runtime.module. For complete SELinux messages run: sealert -l 5fc06daf-4d70-4bf1-9be6-4618972b62f4
Nov 11 10:23:30 hostname platform-python[12788]: SELinux is preventing /usr/libexec/platform-python3.6 from read access on the file /etc/dnf/modules.d/javapackages-runtime.module.#012#012*****  Plugin restorecon (92.2 confidence) suggests   ************************#012#012If you want to fix the label. #012/etc/dnf/modules.d/javapackages-runtime.module default label should be etc_t.#012Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory in which case try to change the following command accordingly.#012Do#012# /sbin/restorecon -v /etc/dnf/modules.d/javapackages-runtime.module#012#012*****  Plugin catchall_boolean (7.83 confidence) suggests   ******************#012#012If you want to allow daemons to dump core#012Then you must tell SELinux about this by enabling the 'daemons_dump_core' boolean.#012#012Do#012setsebool -P daemons_dump_core 1#012#012*****  Plugin catchall (1.41 confidence) suggests   **************************#012#012If you believe that platform-python3.6 should be allowed read access on the javapackages-runtime.module file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'rhsmcertd-worke' --raw | audit2allow -M my-rhsmcertdworke#012# semodule -X 300 -i my-rhsmcertdworke.pp#012


Can provide logs if you think it's needed.
Comment 5 Steffen Froemer 2020-01-29 07:54:28 UTC 
Hi, I faced same issue, when installing a fresh RHEL-8.1 from DVD and perform today's available updates. 
Every 4 hours, I see following SELinux errors

Jan 29 08:01:25 setroubleshoot[10900]: SELinux is preventing /usr/libexec/platform-python3.6 from read access on the file container-tools.module. For complete SELinux messages run: sealert -l c22f225e-c19f-454d-82b1-8bed2de047
c1                                                                                                                                                                                                                                            
Jan 29 08:01:25 setroubleshoot[10900]: SELinux is preventing /usr/libexec/platform-python3.6 from read access on the file llvm-toolset.module. For complete SELinux messages run: sealert -l c22f225e-c19f-454d-82b1-8bed2de047c1
Jan 29 08:01:25 setroubleshoot[10900]: SELinux is preventing /usr/libexec/platform-python3.6 from read access on the file perl-DBD-SQLite.module. For complete SELinux messages run: sealert -l c22f225e-c19f-454d-82b1-8bed2de047
c1                                                                                                                     
Jan 29 08:01:25 setroubleshoot[10900]: SELinux is preventing /usr/libexec/platform-python3.6 from read access on the file perl-DBI.module. For complete SELinux messages run: sealert -l c22f225e-c19f-454d-82b1-8bed2de047c1     
Jan 29 08:01:28 setroubleshoot[10900]: SELinux is preventing /usr/libexec/platform-python3.6 from read access on the file python36.module. For complete SELinux messages run: sealert -l c22f225e-c19f-454d-82b1-8bed2de047c1     
Jan 29 08:01:41 setroubleshoot[10934]: SELinux is preventing /usr/libexec/platform-python3.6 from read access on the file satellite-5-client.module. For complete SELinux messages run: sealert -l c22f225e-c19f-454d-82b1-8bed2de
047c1                                                                                                                  
Jan 29 08:01:54 setroubleshoot[10943]: SELinux is preventing /usr/libexec/platform-python3.6 from read access on the file virt.module. For complete SELinux messages run: sealert -l c22f225e-c19f-454d-82b1-8bed2de047c1  

Indeed, for all those messages, a file in /etc/dnf/modules.d exist.
After restoring SELinux labels, everything works fine, but this isn't a solution in my eyes.

All these files are related to enabled streams

# dnf module list --enabled
Name                                             Stream                                     Profiles                                          Summary                                                                                         
container-tools                                  rhel8 [d][e]                               common [d]                                        Common tools and dependencies for container runtimes                                            
llvm-toolset                                     rhel8 [d][e]                               common [d]                                        LLVM                                                                                            
perl-DBD-SQLite                                  1.58 [d][e]                                common [d]                                        SQLite DBI driver                                                                               
perl-DBI                                         1.641 [d][e]                               common [d]                                        A database access API for Perl                                                                  
python36                                         3.6 [d][e]                                 common [d], build                                 Python programming language, version 3.6                                                        
satellite-5-client                               1.0 [d][e]                                 common [d], gui                                   Red Hat Satellite 5 client packages                                                             

For testing, I enabled another module to see, how the file is created

# dnf module enable swig
# ls -laZ  /etc/dnf/modules.d
-rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0  52 Jan 29 08:46 swig.module

This is completely different to the labels of modules directly after installation

# ls -laZ /etc/dnf/modules.d
total 28                                                                                                                                                                                                                                      
drwxr-xr-x. 2 root root system_u:object_r:etc_t:s0  191 Oct 21 14:27 .
drwxr-xr-x. 8 root root system_u:object_r:etc_t:s0  128 Oct 21 14:27 ..
-rw-r--r--. 1 root root system_u:object_r:root_t:s0  76 Jan 27 17:44 container-tools.module
-rw-r--r--. 1 root root system_u:object_r:root_t:s0  70 Jan 27 17:44 llvm-toolset.module  
-rw-r--r--. 1 root root system_u:object_r:root_t:s0  75 Jan 27 17:44 perl-DBD-SQLite.module
-rw-r--r--. 1 root root system_u:object_r:root_t:s0  62 Jan 27 17:44 perl-DBI.module      
-rw-r--r--. 1 root root system_u:object_r:root_t:s0  60 Jan 27 17:44 python36.module
-rw-r--r--. 1 root root system_u:object_r:root_t:s0  80 Jan 27 17:44 satellite-5-client.module
-rw-r--r--. 1 root root system_u:object_r:root_t:s0  53 Jan 27 17:44 virt.module
Comment 6 Zdenek Pytela 2020-01-29 16:03:26 UTC 
Steffen,

I am not able to reproduce the issue with a clean install from a DVD image of RHEL 8.1 GA. Does it only happen when installed using kickstart, or even with a particular configuration?
Comment 7 Steffen Froemer 2020-01-31 09:56:23 UTC 
Zdenek, I installed from DVD and choose Server with GUI. Afaik this is default on DVD installation.
What your selinux labels does look like after the initial installation?
Comment 9 Joachim Frieben 2020-02-02 12:07:58 UTC 
(In reply to Zdenek Pytela from comment #6)
I have seen this alert today after fully updating a fresh EL 8.1 workstation class installation using the DVD image but not again after relabeling the file system via 'touch /.autorelabel' and rebooting the system.
Comment 10 Steffen Froemer 2020-02-03 16:06:24 UTC 
(In reply to Joachim Frieben from comment #9)
> (In reply to Zdenek Pytela from comment #6)
> I have seen this alert today after fully updating a fresh EL 8.1 workstation
> class installation using the DVD image but not again after relabeling the
> file system via 'touch /.autorelabel' and rebooting the system.

Yes, once the files are relabled, the issue is gone. It also does not occur when enabling new Streams to your system. It only occurs to streams, which are enabled directly after install from DVD.
Comment 12 Zdenek Pytela 2020-03-16 18:18:16 UTC 
Switching the component to anaconda.

Folks, I am not able to reproduce reliably, but it seems like in some RHEL images right after installation files in /etc/dnf/modules.d have incorrect context type: root_t instead of etc_t. This typically happens when a file is created in some directory and then it is moved or copied with preserving attributes to a different directory.

Although the solution is easy, just run "restorecon -Rv /etc/dnf/modules.d", but the context should be correct right after installation.
Comment 16 Robert Scheck 2020-05-10 14:30:00 UTC 
Our GSS case 02643735 is about the same...when will this be fixed?
Comment 18 Robert Scheck 2020-05-11 11:30:09 UTC 
Jan, GSS describes a simple test case in our ticket mentioned in comment #16 (if it helps).
Comment 19 Jan Stodola 2020-05-11 11:41:28 UTC 
Robert, this problem is very easy to reproduce, so I think we have all we need to fix it.
Comment 23 Vladimír Slávik 2020-06-03 14:46:32 UTC 
Preliminary fix PR: https://github.com/rhinstaller/anaconda/pull/2636

This also means customers can work around this right now with trivial %post scripts if desperately needed.
Comment 24 Jiri Konecny 2020-06-04 13:21:33 UTC 
*** Bug 1753377 has been marked as a duplicate of this bug. ***
Comment 27 Zdenek Pytela 2020-06-07 08:52:46 UTC 
*** Bug 1844765 has been marked as a duplicate of this bug. ***
Comment 34 Marek Havrila 2020-07-27 15:43:20 UTC 
Verified on RHEL-8.3.0-20200701.2 and anaconda-33.16.3.10-1.el8.x86_64
Comment 35 Zdenek Pytela 2020-09-29 04:46:52 UTC 
*** Bug 1882974 has been marked as a duplicate of this bug. ***
Comment 38 errata-xmlrpc 2020-11-04 03:22:54 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (anaconda bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:4729
Note You need to log in before you can comment on or make changes to this bug.