Hi Stephen, As part of my software_upgrade procedure, after populating the new policies and selinuxfs on the /inactive side, I did "touch /inactive/.autorelabel" Then reboot my Linux Card. So now when the Card was booting up from the new side... kernel detected new policies, loaded new policies, kernel also detected the .autorelabel file So it invoked automatic "Re-Label" of the filesystem Kernel then FORCED another Automatic REBOOT And then the Card booted up all the way. Now when I do "ps -eZ | grep sshd", I get root@hapWibbSc2:/root> ps -eZ | grep sshd system_u:system_r:init_t:s0 3971 ? 00:00:00 sshd So this way, we've made sure that the filesystem was labeled correctly, before the init processes were started! You mentioned that ideally, this is the sequence we want, correct ??? *BUT*, how even after re-labeling the filesystem, and starting sshd, the context became = system_u:system_r:init_t ?? Now when I ssh in as "Admin", or "Reza" I still get the wrong context ! :-( Things actually seem to work properly when the sshd process is running in context = root:system_r:sshd_t:s0 In my normal setup, I DON'T create an /.autorelabel file, and I do the re-labeling manually via a script using restorecon. The problem with that approach is that, init processes like 'sshd' already get started in the wrong context BEFORE my script gets a chance to run. But if I restart sshd from the console, my ssh headaches get resolved. So how can I restart ssh in the correct context (system_r:sshd_t) via a script? You mentioned something about the "runcon" command... Can I use 'runcon' in my script to restart sshd and force sshd to run it in the correct context ?? You're right that other init processes may be running in the wrong context/domain as well, but they're not bothering me as much. But I need to at least get around this ssh problem... Any suggestions ?... Thanks, - Reza. -----Original Message----- From: Stephen Smalley [mailto:sds@xxxxxxxxxxxxx] Sent: Wednesday, February 13, 2008 8:38 AM To: Hasan Rezaul-CHR010 Cc: Dave Quigley; selinux Subject: RE: Accurately setting Security Context of a user when ssh-ing in On Tue, 2008-02-12 at 18:01 -0500, Hasan Rezaul-CHR010 wrote: > Hi Stephen, > > Here are the outputs of the commands you asked for... > > Before restarting sshd, while the problem is exhibited: > ------------------------------------------------------------------------ ------ > > root@hapWibbSc2:/> cat /selinux/booleans/ssh_sysadm_login > 0 0 > > root@hapWibbSc2:/> grep > ssh /etc/selinux/strict/contexts/default_contexts > system_r:sshd_t:s0 user_r:user_t:s0 staff_r:staff_t:s0 > sysadm_r:sysadm_t:s0 > > > root@hapWibbSc2:/> ps -eZ | grep sshd > system_u:system_r:kernel_t:s0 1095 ? 00:00:00 sshd So here sshd never transitioned into its domain, likely because the filesystem wasn't labeled at the time /sbin/init started. > > > And after restarting sshd from the console, where I am > root:sysadm_r:sysadm_t:s0 > ------------------------------------------------------------------------ -------------------------------------------------- > > root@hapWibbSc2:/> cat /selinux/booleans/ssh_sysadm_login > 0 0 > > root@hapWibbSc2:/> grep > ssh /etc/selinux/strict/contexts/default_contexts > system_r:sshd_t:s0 user_r:user_t:s0 staff_r:staff_t:s0 > sysadm_r:sysadm_t:s0 > > root@hapWibbSc2:/> ps -eZ | grep sshd > root:system_r:sshd_t:s0 4819 ? 00:00:00 sshd And here it is running in the correct context, or close enough (ideally it would be system_u). If you restarted it with run_init /etc/init.d/sshd restart, then that should happen. > Just in case, under the /etc/selinux/strict/contexts/users/ > directory, I only have one file called "root", and that contains: > > ------------------------------------------------------------------------ ------------------------------------------------------------------------ --------------------------- > > system_r:local_login_t:s0 sysadm_r:sysadm_t:s0 staff_r:staff_t:s0 > user_r:user_t:s0 > system_r:crond_t:s0 sysadm_r:sysadm_crond_t:s0 > staff_r:staff_crond_t:s0 user_r:user_crond_t:s0 > staff_r:staff_su_t:s0 sysadm_r:sysadm_t:s0 staff_r:staff_t:s0 > user_r:user_t:s0 > sysadm_r:sysadm_su_t:s0 sysadm_r:sysadm_t:s0 staff_r:staff_t:s0 > user_r:user_t:s0 > user_r:user_su_t:s0 sysadm_r:sysadm_t:s0 staff_r:staff_t:s0 > user_r:user_t:s0 > # > # Uncomment if you want to automatically login as sysadm_r > # > #system_r:sshd_t:s0 sysadm_r:sysadm_t:s0 staff_r:staff_t:s0 > user_r:user_t:s0 > > > *** So given this info, we can see that in the problematic case, > context of sshd is system_u:system_r:kernel_t:s0, but restarting > sshd on the console, we get root:system_r:sshd_t:s0. And after this, > everything works nicely... > > So how can I programmatically (e.g. through a script) get sshd to > start in the right context, or force sshd to change context to > sshd_t ? > > Thanks again for all your help as always :-) Well, I suspect that not only sshd but all of your system processes are running in the wrong domain because init never transitioned out of kernel_t into init_t. Ideally you'd label the filesystem before you perform that first boot of the new system image. Should be possible to do, modulo differences between the file types defined by the old and new policies. If you can at least get most of the files labeled, then init will transition properly and the daemons will follow course. -- Stephen Smalley National Security Agency -- 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.
