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 1753377 - SELinux denial against comm="rhsmcertd-worke" name="satellite-5-client.module"
Summary: SELinux denial against comm="rhsmcertd-worke" name="satellite-5-client.module"
Keywords:
Status: CLOSED DUPLICATE of bug 1775975
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: anaconda
Version: 8.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: 8.0
Assignee: Anaconda Maintenance Team
QA Contact: Release Test Team
URL:
Whiteboard:
: 1753393 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-09-18 18:18 UTC by John Sefler
Modified: 2020-06-04 13:21 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-06-04 13:21:33 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description John Sefler 2019-09-18 18:18:50 UTC 
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
Comment 3 Lukas Vrabec 2019-09-19 11:21:05 UTC 
Hi John, 

Where is please "satellite-5-client.module" located? 

Thanks,
Lukas.
Comment 4 Lukas Vrabec 2019-09-19 11:21:46 UTC 
*** Bug 1753393 has been marked as a duplicate of this bug. ***
Comment 9 Daniel Mach 2019-10-09 07:11:53 UTC 
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.
Comment 10 Rehana 2019-10-11 14:18:58 UTC 
(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
Comment 11 Alex Wood 2019-10-11 18:33:42 UTC 
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.
Comment 12 Lukas Vrabec 2019-10-14 10:37:34 UTC 
(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.
Comment 16 mertensb.mazda 2020-04-30 15:08:18 UTC 
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
Comment 17 Jiri Konecny 2020-06-04 13:21:33 UTC 
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 ***
Note You need to log in before you can comment on or make changes to this bug.