Description of problem: After RHEVH installed, there are sshd_t / local_login_t denials in audit.log Version: rhev-hypervisor6-6.6-20150114.0 ovirt-node-3.2.1-4.el6.noarch selinux-policy-3.7.19-260.el6_6.1.noarch How reproducible: Always. Steps to Reproduce: 1.RHEV-H installed successful. selinux in enforcing mode as default. 2.Login to rhevh, # grep "avc: denied" /var/log/audit/audit.log type=AVC msg=audit(1421815531.062:55): avc: denied { signull } for pid=13845 comm="sshd" scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tclass=process type=AVC msg=audit(1421819372.181:393): avc: denied { signull } for pid=14492 comm="sshd" scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tclass=process # ps -aux|grep ssh Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.8/FAQ root 13837 0.0 0.0 66216 1224 ? Ss 04:45 0:00 /usr/sbin/sshd root 14492 0.0 0.0 95848 4188 ? Ss 05:49 0:00 sshd: admin [priv] admin 14498 0.0 0.0 95848 1900 ? S 05:49 0:00 sshd: admin@pts/0 root 14737 0.0 0.0 7908 852 pts/0 S+ 06:03 0:00 grep ssh Actual results: sshd_t / local_login_t AVC denied msgs in audit.log Expected results: No such avc denied errors in audit.log.
Created attachment 982182 [details] audit.log
Only reproduce this bug on rhevh 6.6 for 3.5 build. For rhevh 7.0 for 3.5, I did not reproduce this bug. because it is related selinux and security, not sure whether we need to fix it on rhev 3.5.0 or rhev 3.5.0-1 or zstream.
Dan, I saw bug #843631 and wonder if we should add a dontaudit or allow rule for the denial above. Do you have a suggestion?
I would guess this is an allow rule, although I have no idea what the connection is between /bin/login and sshd.
Petr, do you have an idea why ssh could be sending signull to login?
DOes it just want the /proc and send signull to all processes?
I've inspected rhel-6 sources and the only case when sshd_t somehow interacts with local_login_t would be if the option UseLogin=yes is set in sshd_conf. And I can't even see any rule which would allow sshd_t to execute login_exec_t thus it should not work anyway. From my point of view it seems to be more mis-configuration than something expected.
Thanks all for the inputs. I cannot reproduce this report in an updated rhev-hypervisor image, example: rhev-hypervisor6-6.6-20150402.0. I am closing this bug for now, fell free to re-open in case you see it again.