Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite 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 "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. 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 "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-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 2012234

Summary: SELinux: sshd denied read
Product: Red Hat Satellite Reporter: Stephen Wadeley <swadeley>
Component: SELinuxAssignee: Lukas Zapletal <lzap>
Status: CLOSED NOTABUG QA Contact: Stephen Wadeley <swadeley>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.10.0CC: lzap, pbrezina
Target Milestone: UnspecifiedKeywords: Regression
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-10-25 14:44:34 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 Stephen Wadeley 2021-10-08 15:45:54 UTC
Description of problem:

While testing for SELinux AVC errors on Sat6.10 snap 21, this error was seen:

time->Tue Oct  5 03:40:45 2021
type=PROCTITLE msg=audit(1633419645.866:3774): proctitle=737368643A20726F6F74205B707269765D
type=SYSCALL msg=audit(1633419645.866:3774): arch=c000003e syscall=2 success=no exit=-13 a0=7fe06012c32e a1=0 a2=0 a3=3 items=0 ppid=1054 pid=77961 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=452 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1633419645.866:3774): avc:  denied  { read } for  pid=77961 comm="sshd" name="lastlog" dev="vda1" ino=12585226 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_log_t:s0 tclass=file permissive=0


Version-Release number of selected component (if applicable):
Sat6.10 snap 21
Sat6.9.7 snap 1

 ~]# rpm -q pam
pam-1.1.8-23.el7.x86_64

~]# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 7.9 (Maipo)

How reproducible:


Steps to Reproduce:
1. get SatLab test VM
2. ausearch -m AVC,USER_AVC
3. Sync some repos
4. ausearch -m AVC,USER_AVC

Actual results:
type=AVC msg=audit(1633419645.866:3774): avc:  denied  { read } for  pid=77961 comm="sshd" name="lastlog" dev="vda1" ino=12585226 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_log_t:s0 tclass=file permissive=0

Expected results:
No AVCs

Comment 1 Brad Buckingham 2021-10-11 13:19:36 UTC
Stephen,

Is there any observed negative impact to Satellite as a result of this behavior?

Can we tell what process was using sshd that resulted in the denial?

Thanks!

ps - Jake said you can reach out to him, if want ;)

Comment 2 Stephen Wadeley 2021-10-11 15:12:04 UTC
Hello Brad

Its only an irritation from Satellite point of view as the logs get filled up:


[root@dhcp-2-207 ~]# ls -laZ /var/log/lastlog
-rw-r--r--. root root system_u:object_r:cron_log_t:s0  /var/log/lastlog
[root@dhcp-2-207 ~]# ls -la /var/log/secure
-rw-------. 1 root root 233678 Oct 11 10:30 /var/log/secure
[root@dhcp-2-207 ~]# ls -la /var/log/secur*
-rw-------. 1 root root 233678 Oct 11 10:30 /var/log/secure
-rw-------. 1 root root   2556 Oct  1 16:44 /var/log/secure-20211003
-rw-------. 1 root root  19354 Oct  9 14:02 /var/log/secure-20211010

I believe this is a PAM issue

/var/log/secure:Oct 11 10:24:34 dhcp-2-207 sshd[33476]: pam_lastlog(sshd:session): unable to open /var/log/lastlog: Permission denied


changing component

Thank you

Comment 6 Iker Pedrosa 2021-10-18 15:16:47 UTC
I've just checked in a clean RHEL7.9 VM and the permissions for the lastlog file differ with your system:
$ ls -laZ /var/log/lastlog
-rw-r--r--. root root system_u:object_r:lastlog_t:s0   /var/log/lastlog

I think that this is happening because your system has cron_log_t. Can you check it? Can you try to change it temporarily (chcon) to lastlog_t and see what happens?

Comment 7 Stephen Wadeley 2021-10-25 08:05:17 UTC
Hello Iker


This is on a system upgraded from Satellite 6.9.6 to Sat6.10
~]# rpm -q satellite
satellite-6.10.0-2.el7sat.noarch
 ~]# ls -laZ /var/log/lastlog
-rw-r--r--. root root unconfined_u:object_r:lastlog_t:s0 /var/log/lastlog


This is on test install of 6.10
~]# rpm -q satellite
satellite-6.10.0-1.el7sat.noarch
[root@dhcp-3-140 ~]# ls -laZ /var/log/lastlog
-rw-r--r--. root root system_u:object_r:cron_log_t:s0  /var/log/lastlog

So looks like this is a Satellite 6.10 issue after all, or possibly some issue related to Sat QEs test images and the change of host name. In any case, its a regression and not a RHEL bug then. I will change component back to Satellite.

 ~]# chcon -t lastlog_t /var/log/lastlog
 ~]# ls -laZ /var/log/lastlog
-rw-r--r--. root root system_u:object_r:lastlog_t:s0   /var/log/lastlog
 ~]# ausearch -m AVC,USER_AVC -ts recent
<no matches>
 ~]# ausearch -m AVC,USER_AVC -ts today
----
time->Mon Oct 25 03:31:28 2021
type=PROCTITLE msg=audit(1635147088.797:29588): proctitle=737368643A20726F6F74205B707269765D
type=SYSCALL msg=audit(1635147088.797:29588): arch=c000003e syscall=2 success=no exit=-13 a0=7f221f78a32e a1=0 a2=0 a3=3 items=0 ppid=1104 pid=29555 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2016 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1635147088.797:29588): avc:  denied  { read } for  pid=29555 comm="sshd" name="lastlog" dev="vda1" ino=12800323 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_log_t:s0 tclass=file permissive=0
[root@dhcp-3-140 ~]# 


I will run some tests to see if I get any more issues.

Thank you Iker


Hello @lzap 

Do you have a fresh install of 6.10 there to check or do you need me to do a manual install in Beaker for you?


Thank you

Comment 11 Stephen Wadeley 2021-10-25 14:44:34 UTC
Hi

running change-host-name script does not seem to be the cause.

I then created a new system in SatLab and it is set that way right at system start:

 ~]# ls -laZ /var/log/lastlog 
-rw-r--r--. root root system_u:object_r:cron_log_t:s0  /var/log/lastlog

but logs do not tell me what set it that way:

~]# grep -r cron_log_t /var/log/
/var/log/audit/audit.log:type=AVC msg=audit(1635168670.155:3410): avc:  denied  { read } for  pid=77492 comm="sshd" name="lastlog" dev="vda1" ino=13053789 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_log_t:s0 tclass=file permissive=0
/var/log/audit/audit.log:type=AVC msg=audit(1635168738.698:3456): avc:  denied  { read } for  pid=77664 comm="sshd" name="lastlog" dev="vda1" ino=13053789 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_log_t:s0 tclass=file permissive=


Anyway, not a product bug, something to do with how our test images are created