sshd daemon is running in unconfined domain, some domain transition is missing in policy. # rpm -qa |grep targeted selinux-policy-targeted-2.4.6-137.1.el5 # ps -efZ|grep sshd user_u:system_r:unconfined_t:SystemLow-SystemHigh root 5206 1 0 21:57 ? 00:00:00 /usr/sbin/sshd # ls -Z /usr/sbin/sshd -rwxr-xr-x root root system_u:object_r:sshd_exec_t /usr/sbin/sshd # ls -Z /etc/rc.d/init.d/sshd -rwxr-xr-x root root system_u:object_r:initrc_exec_t /etc/rc.d/init.d/sshd # ps -efZ|grep init system_u:system_r:init_t root 1 0 0 17:03 ? 00:00:02 init [3]
Please update to the U3 policy and relabel, I believe this is a labeling problem, but you can try out the U3 policy. Preview F3 policy is available on http://people.redhat.com/dwalsh/SELinux/RHEL5
I have installed your rpms: # rpm -qa|grep ^selinux selinux-policy-2.4.6-203.el5 selinux-policy-targeted-2.4.6-203.el5 selinux-policy-devel-2.4.6-203.el5 Same result. I thought I listed all labels involved, did I miss some? user_u:system_r:unconfined_t:SystemLow-SystemHigh root 25114 1 0 21:39 ? 00:00:00 /usr/sbin/sshd
What does pstree show you?
pstree -Z, to be specific. And how was sshd started? Is this after a clean boot or after manual restart or after an update including openssh?
Created attachment 328910 [details] pstree output Just to be sure it's not something I did wrong, I did absolutely fresh minimal installation and result is the same, sshd is running unconfined. I will attach my kickstart file, I am using Redhat 5.2 image.
Created attachment 328912 [details] kickstart file Here is the kickstart I used. I booted using boot.iso and typed in the command line linux cmdline noipv6 ks=http://hut/redhat5.cfg Should be easily reproducable.
That policy contains: typealias unconfined_t alias sshd_t; So sshd_t is unconfined_t in that policy.
Was it intentional? It's strange that a frontier in secure access to a system is insecure itself. There were buffer overflows in openssh in the past.
sshd has always been unconfined under the targeted policy, although these days it runs in an sshd_t domain but that domain is still made unconfined in a targeted configuration (i.e. if the unconfined module is present). The rationale as I understand it is that as sshd necessarily must be able to transition to the unconfined domain upon executing a shell in order to launch unconfined user sessions (the default under targeted policy), there is no point in trying to confine it. strict policy (or these days, targeted policy with the unconfined module removed) does confine sshd.
Yes in RHEL5 we allow the sshd to be unconfined so it can transition to the unconfined_t domain. It is confined in later Fedora releases, but still has broad privs since it is a trusted application and can transition to the unconfined_t domain in targeted policy. Steven it is confined in F10 in that it can not read random locations on the file system, but it can still transition to unconfined_t on login in targeted policy. This prevents certain attacks vulnerabilities on ssh where hackers have been able to get ssh to return data without logging into the system. So sshd is better the an unconfined domain, but if it becomes fully compromised, you still are in trouble.
Ok, that's interesting - upstream refpolicy still has this: $ grep unconfined_domain policy/modules/services/ssh.te unconfined_domain(sshd_t) So I take it that you removed this in the Fedora policy in recent times?
Yes for Fedora 10.