Description of problem: When I start the xinetd I get an avc in the audit log. Version-Release number of selected component (if applicable): RHEL5 snapshot 6 with the selinux-policy-mls-2.4.6-24.el5 MLS policy and the lspp.62 kernel, although the avc was seen with the stock snapshot 6 system as well. How reproducible: very Steps to Reproduce: 1.boot the system with the mls policy in enforcing mode 2.or run "run_init /etc/init.d/xinetd restart" 3.look in the audit log for the avc Actual results: type=AVC msg=audit(1168552545.327:398): avc: denied { execute } for pid=2096 comm="xinetd" name="sshd" dev=dm-0 ino=273220 scontext=system_u:system_r:inetd_t:s0-s15:c0.c1023 tcontext=system_u:object_r:sshd_exec_t:s0 tclass=file type=SYSCALL msg=audit(1168552545.327:398): arch=c0000032 syscall=1049 success=no exit=-13 a0=20000008005ddaea a1=1 a2=2000000800044b07 a3=20000008005e6220 items=0 ppid=2095 pid=2096 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="xinetd" exe="/usr/sbin/xinetd" subj=system_u:system_r:inetd_t:s0-s15:c0.c1023 key=(null) Expected results: No avc Additional info: audit2allow says this: allow inetd_t sshd_exec_t:file execute;
Fixed in selinux-policy-2.4.6-25
I'm now running the MLS selinux-policy-2.4.6-25, along with the other latest packages from Dan's repo and I can no longer ssh into the system. I don't know if the problem is related to fix for this bugzilla but since it involves sshd it seems plausible. If you think its unrelated I can open a different bugzilla. When I attempt to ssh in I get this: <flounder:ljk> ssh cert-i4.zko.hp.com Password: Last login: Thu Jan 11 18:24:36 2007 from flounder.zko.hp.com /bin/bash: Permission denied Connection to cert-i4.zko.hp.com closed. and these messages in the audit log: type=USER_LOGIN msg=audit(1168558670.807:88): user pid=1929 uid=0 auid=500 subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 msg='uid=500: exe="/usr/sbin/sshd" (hostname=flounder.zko.hp.com, addr=16.116.113.236, terminal=/dev/pts/0 res=success)' type=AVC msg=audit(1168558670.808:89): avc: denied { execute_no_trans } for pid=1938 comm="sshd" name="bash" dev=dm-0 ino=1703940 scontext=system_u:system_r:sshd_t:s0-s15:c0.c1023 tcontext=system_u:object_r:shell_exec_t:s0 tclass=filetype=SYSCALL msg=audit(1168558670.808:89): arch=c0000032 syscall=1033 success=no exit=-13 a0=2000000800a99220 a1=60000fffff4194a8 a2=2000000800aabbe0 a3=d items=0 ppid=1937 pid=1938 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts0 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 key=(null) type=AVC_PATH msg=audit(1168558670.808:89): path="/bin/bash" type=CRED_DISP msg=audit(1168558670.863:90): user pid=1929 uid=0 auid=500 subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 msg='PAM: setcred acct=ljk : exe="/usr/sbin/sshd" (hostname=flounder.zko.hp.com, addr=16.116.113.236, terminal=ssh res=success)' type=USER_END msg=audit(1168558670.881:91): user pid=1929 uid=0 auid=500 subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 msg='PAM: session close acct=ljk : exe="/usr/sbin/sshd" (hostname=flounder.zko.hp.com, addr=16.116.113.236, terminal=ssh res=success)' I get similar AVCs with a non-admin account. type=USER_LOGIN msg=audit(1168558813.708:105): user pid=1971 uid=0 auid=501 subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 msg='uid=501: exe="/usr/sbin/sshd" (hostname=flounder.zko.hp.com, addr=16.116.113.236, terminal=/dev/pts/0 res=success)' type=AVC msg=audit(1168558813.709:106): avc: denied { execute_no_trans } for pid=1980 comm="sshd" name="bash" dev=dm-0 ino=1703940 scontext=system_u:system_r:sshd_t:s0-s15:c0.c1023 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file type=SYSCALL msg=audit(1168558813.709:106): arch=c0000032 syscall=1033 success=no exit=-13 a0=2000000800a99220 a1=60000fffffce94a8 a2=2000000800aabc40 a3=d items=0 ppid=1979 pid=1980 auid=501 uid=501 gid=501 euid=501 suid=501 fsuid=501 egid=501 sgid=501 fsgid=501 tty=pts0 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 key=(null) type=AVC_PATH msg=audit(1168558813.709:106): path="/bin/bash" type=CRED_DISP msg=audit(1168558813.762:107): user pid=1971 uid=0 auid=501 subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 msg='PAM: setcred acct=ljknoadmin : exe="/usr/sbin/sshd" (hostname=flounder.zko.hp.com, addr=16.116.113.236, terminal=ssh res=success)' type=USER_END msg=audit(1168558813.780:108): user pid=1971 uid=0 auid=501 subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 msg='PAM: session close acct=ljknoadmin : exe="/usr/sbin/sshd" (hostname=flounder.zko.hp.com, addr=16.116.113.236, terminal=ssh res=success)'
With the latest install couple of installs if sshd is not running as system_u you will not be allowed to login. The way to get ssh back to running as system_u is reboot or from an existing login or console login execute `run_init /etc/init.d/sshd restart`
QE ack for RHEL5.
kylene. sshd should only be started with run_init. If you are sysadmin and you try to run the application any other way in enforcing mode, it should give you permission denied.
Back to the original subject, I no longer get the original AVC but now I get this one when restarting xinetd. type=AVC msg=audit(1168627434.319:280): avc: denied { name_bind } for pid=380 comm="xinetd" src=2222 scontext=system_u:system_r:inetd_t:s0-s15:c0.c1023 tcotext=system_u:object_r:port_t:s0 tclass=tcp_socket type=SYSCALL msg=audit(1168627434.319:280): arch=c0000032 syscall=1191 success=es exit=0 a0=5 a1=60000ffffe5c7708 a2=10 a3=60000ffffe5c7704 items=0 ppid=3839 id=3840 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(non) comm="xinetd" exe="/usr/sbin/xinetd" subj=system_u:system_r:inetd_t:s0-s15:c0c1023 key=(null)
You need to tell selinux this is a valid port for inetd to bind to. semanage port -a -t inetd_child_port_t -p tcp 2222
Regarding comment #4 above where ssh stopped working altogether, I believe its because my previous update picked up the new openssh packages and I hadn't updated my pam configuration as specified in bz 220487. I've done that now and ssh is working again, so ignore comment #4.
Regarding comment #8 above, that avc is due to the /etc/xinetd.d/sshd-mls file installed by the current version of the lspp configuration script. Its either no longer needed or the script needs to register the port so we'll sort that out separately. Thanks for the help.
A package has been built which should help the problem described in this bug report. This report is therefore being closed with a resolution of CURRENTRELEASE. You may reopen this bug report if the solution does not work for you.