Hi R. H. Please see my embedded answers. > Subject: RE: Console Login and SSH Login Security Contexts... > Date: Mon, 1 Nov 2010 17:11:35 -0400 > From: CHR010@motorola.com > To: cpebenito@tresys.com > CC: sds@epoch.ncsc.mil; selinux@tycho.nsa.gov; XLIN1@motorola.com > > > -----Original Message----- > From: Christopher J. PeBenito [mailto:cpebenito@tresys.com] > 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 :-( > If everything is fine, the init program should run in the init_t domain, and its previous domain is kernel_t, which we could observe from /proc/1/attr/*: root@qemu-host:/root> cat /proc/1/attr/current system_u:system_r:init_t:s0-s15:c0.c1023 root@qemu-host:/root> root@qemu-host:/root> cat /proc/1/attr/prev system_u:system_r:kernel_t:s15:c0.c1023 root@qemu-host:/root> If the init on your system remains in the kernel_t, nearly no process on your system would ever run in the correct domain... > As I mentioned, doing a second reboot, does make everything run as its > supposed to ?!? Well, I am wondering what package your init program comes from, if it is sysvinit, then I guess we would have to enable the WITH_SELINUX compile option, so that the init program could detect if SELinux is ever supported by kernel. If yes, it would try to mount selinuxfs and then load the SELinux policy through /selinux/load and then reload itself to ensure it is running in the correct domain. I am not sure, but for me now all I can guess is that a second reboot sounds well like the init program would get a chance to reload itself as described above. See if the updated init program has the same behavior as it used to have. I could be wrong :-P Hope everything works out for you! Cheers, Harry > 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@tycho.nsa.gov with > the words "unsubscribe selinux" without quotes as the message.