-----Original Message----- From: Christopher J. PeBenito [mailto:cpebenito@xxxxxxxxxx] Sent: Tuesday, November 02, 2010 8:37 AM To: Hasan Rezaul-CHR010 Cc: Stephen Smalley; SELinux; Lin Xuejun-XLIN1 Subject: Re: Console Login and SSH Login Security Contexts... On 11/01/10 17:11, Hasan Rezaul-CHR010 wrote: > > -----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). > > 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 ? Is there a .autorelabel or something similar happening during the first boot? If the upgrade is not writing files with the correct label, then the first boot would not have correct transitions, but the second would have the right transitions because the labels on disk were fixed by the autorelabel. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com Thanks Again Chris, There is no .autorelabel being used, (because I didn't want an additional reboot after the autorelabel). What I did was, after the /inactive side was populated with software, and the selinux policies were in place, I used the "setfiles" command to label the /inactive side. The exact command I used is: /sbin/setfiles -r /inactive /inactive/etc/selinux/strict/contexts/files/file_contexts /inactive After this I expect the /inactive side to be labeled appropriately. After this command, I then do a reboot (which makes the /inactive side the new "/" side), and I expect all the services and processes to start up in the correct context... This procedure used to work fine in my older software releases. In the newer software release, not sure why its not working as before. In the new software release, when I do an additional 2nd reboot, then only things start up correctly :-( This is why I am wondering if there are any commands I can run after the 1st reboot, that will correct any context problems ? -- 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.
