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 1887572 - SELinux prevents rhsmcertd-worker from executing the gpgsm file
Summary: SELinux prevents rhsmcertd-worker from executing the gpgsm file
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: selinux-policy
Version: 8.2
Hardware: All
OS: Linux
medium
high
Target Milestone: rc
: 8.5
Assignee: Zdenek Pytela
QA Contact: Milos Malik
URL:
Whiteboard:
: 1959771 1982836 (view as bug list)
Depends On:
Blocks: 2160707
TreeView+ depends on / blocked
 
Reported: 2020-10-12 20:06 UTC by Ryan Mullett
Modified: 2024-12-20 19:18 UTC (History)
15 users (show)

Fixed In Version: selinux-policy-3.14.3-77.el8
Doc Type: Bug Fix
Doc Text:
Cause: The rhsmcertd service was unable to execute gpg or gpgme Consequence: When a repository configuration was changed to "repo_gpgcheck=1", the rhsmcertd worker was unable to perform a GPG signature check on this repository's metadata. Fix: A rule was added to the policy to allow rhsmcertd execute gpg and gpgme Result: The rhsmcertd worker is now able to perform a GPG signature check on the repository's metadata.
Clone Of:
: 2160707 (view as bug list)
Environment:
Last Closed: 2021-11-09 19:42:29 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-2021:4420 0 None None None 2021-11-09 19:42:47 UTC

Internal Links: 2130204

Description Ryan Mullett 2020-10-12 20:06:36 UTC 
Description of problem:
When rhsmcertd is enabled, it sometimes gets denials with selinux enabled.

Version-Release number of selected component (if applicable):
subscription-manager-1.26.20-1.el8.x86_64
selinux-policy-3.14.3-41.el8_2.6.noarch

How reproducible:
Sometimes

Steps to Reproduce:
Do not have exact steps to reproduce, but did confirm that disabling SELinux on the trouble system resolved the issue and allowed rhsmcertd to run normally. Also confirmed several other things, which are mentioned in additional info. 

Actual results:
rhsmcertd does not cause avc denials when run

Expected results:
rhsmcertd causes the following avc denial:
type=AVC msg=audit(XXXXX): avc:  denied  { execute } for  pid=XXXX comm="rhsmcertd-worke" name="gpgsm" dev="dm-0" ino=51144599 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:gpg_exec_t:s0 tclass=file permissive=0

Additional info:
On the system showing the issue the following troubleshooting was performed:

1. Confirmed context on all files coming from subscription-manager
2. Relabelled system just to be sure
3. When the issue occurs there is no timestamps in rhsmcertd.log or rhsm logs that indicate an issue, the only log that displays an issue is the audit log containing the avc denial.
4. There are a few logs related to third-party google-cloud-sdk in the rhsm.log and the rhsmcertd log that seem to indicate an issue that could line up (because of the mention of crypto engine, as well as the gpg_exec_t type in the denial. The issue is that the pid and the timestamps don't line up between the denial and the rhsm logs:

2020-09-11 11:39:48,659 [INFO] rhsmcertd-worker:716862:MainThread @entcertlib.py:131 - certs updated:
Total updates: 0
Found (local) serial# [XXXXX]
Expected (UEP) serial# [XXXXX]
Added (new)
  <NONE>
Deleted (rogue):
  <NONE>
2020-09-11 11:39:52,782 [INFO] rhsmcertd-worker:XXXXXX:MainThread @factlib.py:100 - Facts have been updated.
2020-09-11 11:39:54,567 [ERROR] rhsmcertd-worker:XXXXXX:MainThread @profile.py:81 - Unable to create sack object: Failed to download metadata for repo 'google-cloud-sdk': repomd.xml GPG signature verification error: gpgme_engine_check_version() error: Invalid crypto engine

While the timestamp on the closest audit was the following:

1599838793.967  ==  Fri Sep 11 08:39:53 2020

Same for rhsmcertd.log, nothing that lines up with the September 11 8:39 audit entry:

Fri Sep 11 03:40:07 2020 [INFO] (Cert Check) Certificates updated.
Fri Sep 11 07:39:54 2020 [INFO] (Cert Check) Certificates updated.
Fri Sep 11 11:39:56 2020 [INFO] (Cert Check) Certificates updated.

5. One thing that I did notice is that there is nothing in the subscription-manager package by default that carries the rhsmcertd_t type mentioned in the denial:

[root@localhost ~]# rpm -ql subscription-manager | xargs ls -lZ | grep rhsmcertd_t
[root@localhost ~]#

And on the problem system I did also confirm that nothing appeared to have that context. 

The denial seems to be related to rhsmcertd-worker based on the comm, but again, that had the correct context:

-rwxr-xr-x.   1 root root system_u:object_r:bin_t:s0                  457 Apr 28 16:17 /usr/libexec/rhsmcertd-worker
Comment 3 Svein Olav Bjerkeset 2021-01-08 10:46:39 UTC 
We see the same AVC on all three servers we have with RHEL 8.2 that has the Google Cloud SDK repo enabled. Other 8.2 servers with other external repos does not get the AVC. We will try to add the repo to a 8.3 server and see if it gets the AVC.
Comment 4 Zdenek Pytela 2021-05-19 08:51:46 UTC 
*** Bug 1959771 has been marked as a duplicate of this bug. ***
Comment 6 Zdenek Pytela 2021-07-16 07:13:50 UTC 
*** Bug 1982836 has been marked as a duplicate of this bug. ***
Comment 7 Zdenek Pytela 2021-07-16 07:15:42 UTC 
Note in the duplicate bz it is gpg which is executed:
type=AVC msg=audit(1626266161.404:102781): avc:  denied  { execute } for  pid=635719 comm="rhsmcertd-worke" name="gpg" dev="sdc" ino=144374 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:gpg_exec_t:s0 tclass=file permissive=0
type=SYSCALL msg=audit(1626266161.404:102781): arch=x86_64 syscall=execve success=no exit=EACCES a0=557662993060 a1=7ffd40ed5870 a2=7ffd40edb500 a3=0 items=0 ppid=635718 pid=635719 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)
Comment 10 Kyle Walker 2021-07-21 20:14:47 UTC 
This only happens when you are dealing with a repository with repo_gpgcheck=1 set. It's particularly due to this operation in rhsmcertd where it executes in the rhsmcertd_t context:

/usr/lib64/python3.6/site-packages/rhsm/profile.py
    <snip>
        if dnf is not None and libdnf is not None:
            base = dnf.Base()
            # Read yum/dnf variables from <install_root>/etc/yum/vars and <install_root>/etc/dnf/vars
            # See: https://bugzilla.redhat.com/show_bug.cgi?id=1863039
            base.conf.substitutions.update_from_etc(base.conf.installroot)
            base.read_all_repos()
            try:
                base.fill_sack()
            except dnf.exceptions.RepoError as err:
                log.error("Unable to create sack object: %s" % str(err))
                return []
            # FIXME: DNF doesn't provide public API for modulemd
            try:
                modules = base._moduleContainer
            except AttributeError:
                log.warning("DNF does not provide modulemd functionality")
                return []
            all_module_list = modules.getModulePackages()
    <snip>


Reproducer:

File - /etc/yum.repos.d/google-cloud-sdk.repo

    [google-cloud-sdk]
    name=Google Cloud SDK
    baseurl=https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64
    enabled=1
    gpgcheck=1
    repo_gpgcheck=1
    gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
           https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg


File - /root/repro.py

    #!/usr/bin/python3

    import dnf

    def main():
        with open('/proc/self/attr/current') as filp:
            print(filp.read())

        base = dnf.Base()
        # Read yum/dnf variables from <install_root>/etc/yum/vars and <install_root>/etc/dnf/vars
        # See: https://bugzilla.redhat.com/show_bug.cgi?id=1863039
        base.conf.substitutions.update_from_etc(base.conf.installroot)
        base.read_all_repos()
        try:
            base.fill_sack()
        except dnf.exceptions.RepoError as err:
            print("Unable to create sack object: %s" % str(err))
            return []
    
    if __name__ == "__main__":
        main()

File - /etc/systemd/system/test.service:

    [Unit]
    Description=Testing selinux and DNF

    [Service]
    ExecStart=/root/repro.py

Steps:
 1) # chcon -t rhsmcertd_exec_t repro.py
 2) # systemctl start test

With "setenforce 1":

    # journalctl -u test
    -- Logs begin at Wed 2021-07-21 15:44:47 EDT, end at Wed 2021-07-21 15:47:38 EDT. --
    Jul 21 15:47:33 localhost.localdomain systemd[1]: Started Testing selinux and DNF.
    Jul 21 15:47:34 localhost.localdomain repro.py[9479]: system_u:system_r:rhsmcertd_t:s0
    Jul 21 15:47:34 localhost.localdomain repro.py[9479]: Unable to create sack object: Failed to download metadata for repo 'google-c>
    Jul 21 15:47:34 localhost.localdomain systemd[1]: test.service: Succeeded.
    
    # ausearch -m avc,user_avc -i
    ----
    type=PROCTITLE msg=audit(07/21/2021 15:47:34.258:993) : proctitle=/usr/bin/python3 /root/repro.py 
    type=SYSCALL msg=audit(07/21/2021 15:47:34.258:993) : arch=x86_64 syscall=execve success=no exit=EACCES(Permission denied) a0=0x564b88b94bd0 a1=0x7ffcf0d10850 a2=0x7ffcf0d120f0 a3=0x0 items=0 ppid=9484 pid=9485 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=repro.py exe=/usr/libexec/platform-python3.6 subj=system_u:system_r:rhsmcertd_t:s0 key=(null) 
    type=AVC msg=audit(07/21/2021 15:47:34.258:993) : avc:  denied  { execute } for  pid=9485 comm=repro.py name=gpg dev="dm-0" ino=457473 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:gpg_exec_t:s0 tclass=file permissive=0
    ----
    type=PROCTITLE msg=audit(07/21/2021 15:47:34.260:994) : proctitle=/usr/bin/python3 /root/repro.py 
    type=SYSCALL msg=audit(07/21/2021 15:47:34.260:994) : arch=x86_64 syscall=execve success=no exit=EACCES(Permission denied) a0=0x564b88b94bf0 a1=0x7ffcf0d10850 a2=0x7ffcf0d120f0 a3=0x0 items=0 ppid=9486 pid=9487 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=repro.py exe=/usr/libexec/platform-python3.6 subj=system_u:system_r:rhsmcertd_t:s0 key=(null) 
    type=AVC msg=audit(07/21/2021 15:47:34.260:994) : avc:  denied  { execute } for  pid=9487 comm=repro.py name=gpgsm dev="dm-0" ino=455484 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:gpg_exec_t:s0 tclass=file permissive=0


With "setenforce 0":

    # journalctl -u test
    -- Logs begin at Wed 2021-07-21 15:50:04 EDT, end at Wed 2021-07-21 15:50:13 EDT. --
    Jul 21 15:50:11 localhost.localdomain systemd[1]: Started Testing selinux and DNF.
    Jul 21 15:50:12 localhost.localdomain repro.py[9549]: system_u:system_r:rhsmcertd_t:s0
    Jul 21 15:50:12 localhost.localdomain systemd[1]: test.service: Succeeded.

    # ausearch -m avc,user_avc -i
    ----
    type=PROCTITLE msg=audit(07/21/2021 15:50:11.396:1003) : proctitle=/usr/bin/gpg --version
    type=PATH msg=audit(07/21/2021 15:50:11.396:1003) : item=0 name=/lib64/ld-linux-x86-64.so.2 inode=4240018 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:ld_so_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
    type=CWD msg=audit(07/21/2021 15:50:11.396:1003) : cwd=/
    type=EXECVE msg=audit(07/21/2021 15:50:11.396:1003) : argc=2 a0=/usr/bin/gpg a1=--version
    type=SYSCALL msg=audit(07/21/2021 15:50:11.396:1003) : arch=x86_64 syscall=execve success=yes exit=0 a0=0x5611c3c8fd20 a1=0x7ffd1a057e30 a2=0x7ffd1a0596d0 a3=0x0 items=1 ppid=1 pid=9555 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=gpg exe=/usr/bin/gpg subj=system_u:system_r:rhsmcertd_t:s0 key=(null)
    type=AVC msg=audit(07/21/2021 15:50:11.396:1003) : avc:  denied  { map } for  pid=9555 comm=gpg path=/usr/bin/gpg dev="dm-0" ino=457473 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:gpg_exec_t:s0 tclass=file permissive=1
    type=AVC msg=audit(07/21/2021 15:50:11.396:1003) : avc:  denied  { execute_no_trans } for  pid=9555 comm=repro.py path=/usr/bin/gpg dev="dm-0" ino=457473 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:gpg_exec_t:s0 tclass=file permissive=1 
    type=AVC msg=audit(07/21/2021 15:50:11.396:1003) : avc:  denied  { read open } for  pid=9555 comm=repro.py path=/usr/bin/gpg dev="dm-0" ino=457473 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:gpg_exec_t:s0 tclass=file permissive=1 
    type=AVC msg=audit(07/21/2021 15:50:11.396:1003) : avc:  denied  { execute } for  pid=9555 comm=repro.py name=gpg dev="dm-0" ino=457473 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:gpg_exec_t:s0 tclass=file permissive=1
    ----
    type=PROCTITLE msg=audit(07/21/2021 15:50:11.585:1004) : proctitle=/usr/bin/python3 /root/repro.py 
    type=SYSCALL msg=audit(07/21/2021 15:50:11.585:1004) : arch=x86_64 syscall=openat success=yes exit=16 a0=0xffffff9c a1=0x5611c3c9bd30 a2=O_RDONLY a3=0x0 items=0 ppid=1 pid=9549 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=repro.py exe=/usr/libexec/platform-python3.6 subj=system_u:system_r:rhsmcertd_t:s0 key=(null) 
    type=AVC msg=audit(07/21/2021 15:50:11.585:1004) : avc:  denied  { open } for  pid=9549 comm=repro.py path=/etc/dnf/modules.d/virt.module dev="dm-0" ino=4194444 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=file permissive=1 
    type=AVC msg=audit(07/21/2021 15:50:11.585:1004) : avc:  denied  { read } for  pid=9549 comm=repro.py name=virt.module dev="dm-0" ino=4194444 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=file permissive=1


Individual failures:

> The selinux policy for rhsmcertd_t doesn't allow access to the requisite contexts to interact with the gpg-agent properly. This is necessary in the repo_gpgcheck=1 use-case. According to audit2allow, this should be:

    allow rhsmcertd_t gpg_exec_t:file map;
    allow rhsmcertd_t gpg_exec_t:file { execute execute_no_trans open read };


> The rhsmcertd process makes use of private dnf API calls to enumerate modules. This results in the secondary failure above. Note, restoring the contexts moves it to etc_t. This looks to be an artifact of a previous bug (https://bugzilla.redhat.com/show_bug.cgi?id=1775975). 

I would recommend that we primarily target the first failure above in the form of an selinux-policy update to allow the requisite GPG agent access. Is this sufficient to get the policy updated?
Comment 11 Zdenek Pytela 2021-07-30 17:02:39 UTC 
(In reply to Kyle Walker from comment #10)
> Individual failures:
> 
> > The selinux policy for rhsmcertd_t doesn't allow access to the requisite contexts to interact with the gpg-agent properly. This is necessary in the repo_gpgcheck=1 use-case. According to audit2allow, this should be:
> 
>     allow rhsmcertd_t gpg_exec_t:file map;
>     allow rhsmcertd_t gpg_exec_t:file { execute execute_no_trans open read };
> 
> 
> > The rhsmcertd process makes use of private dnf API calls to enumerate modules. This results in the secondary failure above. Note, restoring the contexts moves it to etc_t. This looks to be an artifact of a previous bug (https://bugzilla.redhat.com/show_bug.cgi?id=1775975). 
> 
> I would recommend that we primarily target the first failure above in the
> form of an selinux-policy update to allow the requisite GPG agent access. Is
> this sufficient to get the policy updated?

If we are able to reproduce it, it should be sufficient, thank you for the analysis. 

Note the other problem:
    ----
    type=PROCTITLE msg=audit(07/21/2021 15:50:11.585:1004) : proctitle=/usr/bin/python3 /root/repro.py 
    type=SYSCALL msg=audit(07/21/2021 15:50:11.585:1004) : arch=x86_64 syscall=openat success=yes exit=16 a0=0xffffff9c a1=0x5611c3c9bd30 a2=O_RDONLY a3=0x0 items=0 ppid=1 pid=9549 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=repro.py exe=/usr/libexec/platform-python3.6 subj=system_u:system_r:rhsmcertd_t:s0 key=(null) 
    type=AVC msg=audit(07/21/2021 15:50:11.585:1004) : avc:  denied  { open } for  pid=9549 comm=repro.py path=/etc/dnf/modules.d/virt.module dev="dm-0" ino=4194444 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=file permissive=1 
    type=AVC msg=audit(07/21/2021 15:50:11.585:1004) : avc:  denied  { read } for  pid=9549 comm=repro.py name=virt.module dev="dm-0" ino=4194444 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=file permissive=1

we will not address in selinux-policy. If it is an issue, another bz needs to be created on anaconda or other component responsible for the /etc/dnf/modules.d/virt.module file deployment - the file has incorrect label. It may have already been resolved with:

https://bugzilla.redhat.com/show_bug.cgi?id=1775975
Comment 13 Zdenek Pytela 2021-08-11 16:17:28 UTC 
I've submitted a Fedora PR to address the issue:
https://github.com/fedora-selinux/selinux-policy/pull/830
Comment 20 errata-xmlrpc 2021-11-09 19:42:29 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 (selinux-policy 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-2021:4420
Comment 21 Red Hat Bugzilla 2023-09-18 00:22:46 UTC 
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days
Note You need to log in before you can comment on or make changes to this bug.