Bug 1753377
| Summary: | SELinux denial against comm="rhsmcertd-worke" name="satellite-5-client.module" | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | John Sefler <jsefler> |
| Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> |
| Status: | CLOSED DUPLICATE | QA Contact: | Release Test Team <release-test-team-automation> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8.1 | CC: | awood, csnyder, dmach, jkonecny, lvrabec, mcoufal, mertensb.mazda, mmalik, plautrba, redakkan, sbroz, ssekidde, vkadlcik, zpytela |
| Target Milestone: | rc | Keywords: | Reopened |
| Target Release: | 8.0 | Flags: | pm-rhel:
mirror+
|
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-06-04 13:21:33 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: | |||
Hi John, Where is please "satellite-5-client.module" located? Thanks, Lukas. *** Bug 1753393 has been marked as a duplicate of this bug. *** John, are you really sure that no files are moved from one directory to another or copied into test environment from outside? Lukas and me have reviewed all possibilities and nothing indicates that DNF does anything wrong. I have also verified that dnf-automatic.timer writes .module files with the correct selinux label. Another possibility is that subscription-manager has special selinux policy that causes the "root_t" label. Since dnf is used as a library and not a standalone program, selinux rules specific to subscription-manager would apply. (In reply to Daniel Mach from comment #9) > John, > are you really sure that no files are moved from one directory to another > or copied into test environment from outside? > Lukas and me have reviewed all possibilities and nothing indicates > that DNF does anything wrong. > > I have also verified that dnf-automatic.timer writes .module files with the > correct selinux label. > > Another possibility is that subscription-manager has special selinux policy > that causes the "root_t" label. > Since dnf is used as a library and not a standalone program, selinux rules > specific to subscription-manager would app Adding more details to clarify A beaker system used for manual testing was also able to hit the same error when rhsmcertd was executed type=AVC msg=audit(1570764126.695:764): avc: denied { read } for pid=31451 comm="rhsmcertd-worke" name="satellite-5-client.module" dev="dm-0" ino=135 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=file permissive=0 @chris, Can you answer this question for Daniel thanks, Rehana After some investigation with John Sefler, we discovered the following:
* Provisioning a system from Beaker using the RHEL-8.1.0-20191003.0 distro (BaseOS variant) results in the installation of the @core group.
* The @core group contains <libcomps.Package object 'rhn-client-tools' at 0x7f09a04e4cf0> which resolves to rhn-client-tools-2.8.16-13.module+el8.1.0+3455+3ddf2832.x86_64
* Installing that package results in the writing of the file /etc/dnf/modules.d/satellite-5-client.module
* When I installed that package *by hand* on a machine I provisioned without Beaker and without a kickstart, the satellite-5-client.module file is laid down with the correct context `etc_t`.
[root@localhost modules.d]# ls -lZ /etc/dnf/modules.d
-rw-r--r--. 1 root root system_u:object_r:etc_t:s0 80 Oct 11 12:47 satellite-5-client.module
* When Beaker's kickstart installs rhn-client-tools, the context is `root_t` but running a restorecon on the file fixes it
[root@kvm-guest-03 ~]# ls -alZ /etc/dnf/modules.d; restorecon -ir /etc/dnf/modules.d/* ; ls -alZ /etc/dnf/modules.d
total 8
-rw-r--r--. 1 root root system_u:object_r:root_t:s0 80 Oct 11 12:47 satellite-5-client.module
-rw-r--r--. 1 root root system_u:object_r:root_t:s0 53 Oct 11 12:47 virt.module
total 8
-rw-r--r--. 1 root root system_u:object_r:etc_t:s0 80 Oct 11 12:47 satellite-5-client.module
-rw-r--r--. 1 root root system_u:object_r:etc_t:s0 53 Oct 11 12:47 virt.module
* This general problem of incorrect labeling problem seems to be a known issue. We found a temporary kickstart script (/tmp/ks-script-_0j3e8zz) that runs restorecon on multiple directories along with the comment
# We need to handle SELinux relabeling for a few reasons:
# - %post scripts that write files into places in /etc, but don't do
# labeling correctly
# - Anaconda code that does the same (e.g. moving our log files into
# /var/log/anaconda)
# - ostree payloads, where all of the labeling of /var is the installer's
# responsibility (see https://github.com/ostreedev/ostree/pull/872 )
There were numerous paths being restored in that script but /etc/dnf/modules.d was not among them. I could not determine where the body of this script originated from as it was not in a %post section of the Kickstart, nor could I determine if the script had actually run. (If restorecon runs are logged, I didn't see them grepping through /var/log).
Accordingly:
* My intuition is that we are seeing an Anaconda bug since with manual install, dnf write the module file with the correct SELinux context
* If the Kickstart script that we discovered actually does run and thus restorecons all the directories it lists, adding /etc/dnf/modules to the list would be a quick, if inelegant, fix.
(In reply to Alex Wood from comment #11) ... ... ... Alex Thanks for investigation, I agree with your finds. > Accordingly: > > * My intuition is that we are seeing an Anaconda bug since with manual > install, dnf write the module file with the correct SELinux context ^ If there is a bug in anaconda, we would see similar issues also on another objects. AFAIK, I know only about this issues. > * If the Kickstart script that we discovered actually does run and thus > restorecons all the directories it lists, adding /etc/dnf/modules to the > list would be a quick, if inelegant, fix. ^^^ This make sense to me Thanks, Lukas. I am seeing this on a newly installed (via anaconda GUI, no kickstart) RHEL 8.1 machine fully updated. This is a minimal installation. The file was incorrectly labeled as well: [root@v-bz-2 conf.d]# ls -alZ /etc/dnf/modules.d; restorecon -ir /etc/dnf/modules.d/* ; ls -alZ /etc/dnf/modules.d total 60 drwxr-xr-x. 2 root root system_u:object_r:etc_t:s0 4096 Feb 18 14:20 . drwxr-xr-x. 8 root root system_u:object_r:etc_t:s0 128 Apr 30 09:33 .. -rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0 54 Apr 27 11:02 httpd.module -rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0 70 Apr 27 17:28 llvm-toolset.module -rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0 59 Apr 27 16:22 mariadb.module -rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0 83 Apr 27 17:28 perl-App-cpanminus.module -rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0 74 Apr 27 16:22 perl-DBD-MySQL.module -rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0 66 Apr 27 17:28 perl-DBD-Pg.module -rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0 75 Apr 27 17:28 perl-DBD-SQLite.module -rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0 62 Apr 27 16:22 perl-DBI.module -rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0 63 Apr 27 17:28 perl-FCGI.module -rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0 63 Apr 27 17:28 perl-YAML.module -rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0 60 Apr 27 16:22 python36.module -rw-r--r--. 1 root root system_u:object_r:root_t:s0 80 Feb 7 15:52 satellite-5-client.module -rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0 65 Apr 27 17:28 subversion.module -rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0 53 Apr 27 17:28 virt.module total 60 drwxr-xr-x. 2 root root system_u:object_r:etc_t:s0 4096 Feb 18 14:20 . drwxr-xr-x. 8 root root system_u:object_r:etc_t:s0 128 Apr 30 09:33 .. -rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0 54 Apr 27 11:02 httpd.module -rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0 70 Apr 27 17:28 llvm-toolset.module -rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0 59 Apr 27 16:22 mariadb.module -rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0 83 Apr 27 17:28 perl-App-cpanminus.module -rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0 74 Apr 27 16:22 perl-DBD-MySQL.module -rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0 66 Apr 27 17:28 perl-DBD-Pg.module -rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0 75 Apr 27 17:28 perl-DBD-SQLite.module -rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0 62 Apr 27 16:22 perl-DBI.module -rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0 63 Apr 27 17:28 perl-FCGI.module -rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0 63 Apr 27 17:28 perl-YAML.module -rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0 60 Apr 27 16:22 python36.module -rw-r--r--. 1 root root system_u:object_r:etc_t:s0 80 Feb 7 15:52 satellite-5-client.module -rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0 65 Apr 27 17:28 subversion.module -rw-r--r--. 1 root root unconfined_u:object_r:etc_t:s0 53 Apr 27 17:28 virt.module All of the following files would be relabeled after a clean installation and installation of updates: # restorecon -rinv / Would relabel /boot/loader/entries/cad8520da2344fbf950bc7413a022b63-4.18.0-147.el8.x86_64.conf from system_u:object_r:modules_object_t:s0 to system_u:object_r:boot_t:s0 Would relabel /boot/loader/entries/cad8520da2344fbf950bc7413a022b63-0-rescue.conf from system_u:object_r:modules_object_t:s0 to system_u:object_r:boot_t:s0 Would relabel /boot/loader/entries/cad8520da2344fbf950bc7413a022b63-4.18.0-147.8.1.el8_1.x86_64.conf from system_u:object_r:modules_object_t:s0 to system_u:object_r:boot_t:s0 Would relabel /boot/loader/entries/cad8520da2344fbf950bc7413a022b63-4.18.0-193.el8.x86_64.conf from system_u:object_r:modules_object_t:s0 to system_u:object_r:boot_t:s0 Would relabel /run/vmware from system_u:object_r:var_run_t:s0 to system_u:object_r:vmware_host_pid_t:s0 Would relabel /run/vmware/guestServicePipe from system_u:object_r:var_run_t:s0 to system_u:object_r:vmware_host_pid_t:s0 Would relabel /run/fsck/sda.lock from system_u:object_r:fsadm_var_run_t:s0 to system_u:object_r:var_run_t:s0 Would relabel /sys/firmware/efi from system_u:object_r:sysfs_t:s0 to system_u:object_r:efivarfs_t:s0 Would relabel /etc/dnf/modules.d/satellite-5-client.module from system_u:object_r:root_t:s0 to system_u:object_r:etc_t:s0 This seems to be a duplicate of bug 1775975 which is already fixed. Closing this bug now. Feel free to reopen if I'm not correct. *** This bug has been marked as a duplicate of bug 1775975 *** |
Description of problem: Encountered the following AVC denial during an automation testrun on a FIPs RHEL8.1 External Snapshot 4 system on all arches (aarch64, ppc64le, s390x, x86_64). I have not seen this before.... From /var/log/audit/audit.log... type=AVC msg=audit(1568755064.321:4507): avc: denied { read } for pid=2827 comm="rhsmcertd-worke" name="satellite-5-client.module" dev="dm-0" ino=135 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=file permissive=0 Version-Release number of selected component (if applicable): subscription-manager-1.25.15-1.el8 selinux-policy-3.14.3-20.el8.noarch How reproducible: It did not appear on testruns for RHEL-8.1.0-Snapshot-3.0 It first appeared on testruns for RHEL-8.1.0-Snapshot-4.0 (on every arch) Steps to Reproduce: Do not know how to manually reproduce. Actual results: above AVC denial found in /var/log/audit/audit.log Expected results: no AVC denials