-----Original Message----- From: Christopher J. PeBenito [mailto:cpebenito@xxxxxxxxxx] Sent: Monday, November 01, 2010 11:00 AM To: Hasan Rezaul-CHR010 Cc: Stephen Smalley; SELinux Subject: Re: Console Login and SSH Login Security Contexts... On 10/31/10 18:36, Hasan Rezaul-CHR010 wrote: > Hi All, > > I know there was a huge email thread recently regarding obtaining > correct security context after SSH-login, but I didn't really get the > answer I need from that thread. So hoping someone can help me... [...] > After the software_upgrade (when the filesystem has already been > labeled correctly, and after the reboot, I would expect the "login" > process and the "sshd" process to run under the correct context > (system_u:system_r:login_exec_t), (system_u:system_r:sshd_exec_t). > But I don't :-( I see them both running as > system_u:system_r:kernel_t !!! This tells me that the domain > transitions during the init sequence perhaps didn't go smoothly ? This is the first problem. It sounds like your init program (typically /sbin/init) is not labeled correctly, which means you don't transition out of kernel_t when init runs, meaning anything that starts up from init/init scripts will almost certainly have the wrong context. The init program should be init_exec_t. I would expect sshd to have the sshd_t domain and local login would be local_login_t (getty processes getty_t). -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com Thanks Chris, It seems that my /sbin/init program is infact labeled correctly as (system_u:object_r:init_exec_t). But the sshd and login processes are still running in the kernel_t domain :-( As I mentioned, doing a second reboot, does make everything run as its supposed to ?!? Like I said, I cant really afford this extra reboot due to timing constraints. - Is there anything I can do via script to set things right ? - Can I force the domain of the sshd and login processes to change to sshd_t and local_login_t. - I am guessing there are other init processes that are also running in the wrong domain! Is there anything I can do to fix all such processes in one shot without requiring a reboot ? Also, in my previous software releases (where we had older Linux 2.6.21, and older selinux packages with Fedora base policy), we never had this problem. But in my new software release (with Linux 2.6.27, and with refpolicy as a starting base), we are seeing this weird problem. Any other suggestions ? Anything else we can do to ensure that the domain transitions happen properly after the first reboot ? What about using the "run_init" command ? Is that advisable ? What other init processes should we check to verify their running domain ? Thanks as always, R.H. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
