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 - SELinux: sshd denied read
Summary: SELinux: sshd denied read
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: SELinux
Version: 6.10.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: Unspecified
Assignee: Lukas Zapletal
QA Contact: Stephen Wadeley
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-10-08 15:45 UTC by Stephen Wadeley
Modified: 2021-11-01 08:22 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-10-25 14:44:34 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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


Note You need to log in before you can comment on or make changes to this bug.