Bug 1775975
| Summary: | SELinux is preventing /usr/libexec/platform-python3.6 from read access on the file virt.module | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Joachim Frieben <jfrieben> |
| Component: | anaconda | Assignee: | Vladimír Slávik <vslavik> |
| Status: | CLOSED ERRATA | QA Contact: | Release Test Team <release-test-team-automation> |
| Severity: | medium | Docs Contact: | bilhar |
| Priority: | medium | ||
| Version: | 8.1 | CC: | anaconda-maint-list, cchouhan, chinodesuuu, dmach, e.lania, jsefler, jstodola, kwalker, lkardos, lvrabec, mhavrila, mkenjale, mmalik, mmatsuya, mwest, nmavrogi, pasik, plautrba, plawate, rboza89, redhat-bugzilla, rvykydal, sbroz, sbueno, sfroemer, sjalgaon, ssekidde, vkadlcik, vslavik, zpytela |
| Target Milestone: | rc | Keywords: | TestCaseNeeded, Triaged |
| Target Release: | 8.3 | Flags: | pm-rhel:
mirror+
|
| Hardware: | noarch | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-11-04 03:22:54 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1825061 | ||
Hi Joachim, Do you know where is file "virt.module" located? Thanks, Lukas. 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. Hi Dan, I think we saw this in past. Again I believe this is bad labeling in /etc/dnf/modules.d directory. 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. 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 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? 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? (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. (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. 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. Our GSS case 02643735 is about the same...when will this be fixed? Jan, GSS describes a simple test case in our ticket mentioned in comment #16 (if it helps). Robert, this problem is very easy to reproduce, so I think we have all we need to fix it. 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. *** Bug 1753377 has been marked as a duplicate of this bug. *** *** Bug 1844765 has been marked as a duplicate of this bug. *** Verified on RHEL-8.3.0-20200701.2 and anaconda-33.16.3.10-1.el8.x86_64 *** Bug 1882974 has been marked as a duplicate of this bug. *** 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 |
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