Bug 1744234

Summary: SELinux denial against lscpu on read/write during rhsmcertd_t context
Product: Red Hat Enterprise Linux 8 Reporter: John Sefler <jsefler>
Component: selinux-policyAssignee: Zdenek Pytela <zpytela>
Status: CLOSED ERRATA QA Contact: Milos Malik <mmalik>
Severity: high Docs Contact:
Priority: urgent    
Version: 8.1CC: csnyder, gcase, lvrabec, mmalik, plautrba, ssekidde, zpytela, zveleba
Target Milestone: rcKeywords: Patch
Target Release: 8.2Flags: pm-rhel: mirror+
Hardware: ppc64le   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-28 16:41:05 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:

Description John Sefler 2019-08-21 15:22:30 UTC
Description of problem:
Encountered the following AVC denials during an automation testrun on a FIPs RHEL8.1 External Snapshot 2 system on a ppc64le system.  I have not seen this before....

From /var/log/audit/audit.log...

type=AVC msg=audit(1566345628.643:5595): avc: denied { read write } for pid=23747 comm="lscpu" name="LCK..librtas" dev="tmpfs" ino=23098 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:rtas_errd_var_lock_t:s0 tclass=file permissive=0

Version-Release number of selected component (if applicable):
subscription-manager-1.25.14-1.el8.ppc64le
selinux-policy-3.14.3-18.el8.noarch

Comment 22 Zdenek Veleba 2020-03-03 14:15:10 UTC
Is this really fixed? I've encountered the similar issue on ppc64le, RHEL-8.2.0-20200225.0.

SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      31
selinux-policy-3.14.3-30.el8.noarch
----
time->Tue Feb 25 11:43:46 2020
type=PROCTITLE msg=audit(1582649026.804:72): proctitle="/usr/bin/lscpu"
type=SYSCALL msg=audit(1582649026.804:72): arch=c0000015 syscall=286 success=no exit=-13 a0=ffffffffffffff9c a1=7fff82e67660 a2=2 a3=0 items=0 ppid=7175 pid=7226 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="lscpu" exe="/usr/bin/lscpu" subj=system_u:system_r:rhsmcertd_t:s0 key=(null)
type=AVC msg=audit(1582649026.804:72): avc:  denied  { write } for  pid=7226 comm="lscpu" name="mem" dev="devtmpfs" ino=11265 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:memory_device_t:s0 tclass=chr_file permissive=0
----
time->Tue Feb 25 11:43:47 2020
type=PROCTITLE msg=audit(1582649027.654:73): proctitle=2F7573722F6C6962657865632F706C6174666F726D2D707974686F6E002F7573722F6C6962657865632F7268736D63657274642D776F726B6572
type=SYSCALL msg=audit(1582649027.654:73): arch=c0000015 syscall=286 success=no exit=-13 a0=ffffffffffffff9c a1=10038bd80d0 a2=0 a3=0 items=0 ppid=2156 pid=7175 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)
type=AVC msg=audit(1582649027.654:73): avc:  denied  { read } for  pid=7175 comm="rhsmcertd-worke" name="satellite-5-client.module" dev="dm-0" ino=33554564 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=file permissive=0

Comment 23 Milos Malik 2020-03-03 14:26:28 UTC
The first SELinux denial should be reported as a new bug, because this bug is related to rhsmcertd_t and rtas_errd_var_lock_t.

The second SELinux denial is already reported as:
 * https://bugzilla.redhat.com/show_bug.cgi?id=1753377
 * https://bugzilla.redhat.com/show_bug.cgi?id=1775975

Comment 25 errata-xmlrpc 2020-04-28 16:41:05 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, 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:1773

Comment 26 Red Hat Bugzilla 2023-09-14 05:42:06 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days