On Fri, 2010-04-30 at 16:32 -0400, Hasan Rezaul-CHR010 wrote: > Hi All, > > I have employed SELinux on our Linux product for a few years now and > have written some simple custom policies on top of the base Fedora Core > 7 'strict' policy. > > I am using Standard Linux 2.6.14. And the SELinux related packages I am > using are: > > checkpolicy 1.34.1 > libselinux 1.34.7 > libsemanage 1.10.3 > libsepol 1.16.1 > policycoreutils 1.34.6 > > I have the following user mappings and login mappings defined: > > root@hapWibbSc2:/var# semanage login -l > > Login Name SELinux User MLS/MCS Range > > > __default__ user_u s0 > > admin staff_u s0 > > root root s0-s0:c0.c1023 > > system_u system_u s0-s0:c0.c1023 > > > > root@hapWibbSc2:/var# semanage user -l > > Labeling MLS/ MLS/ > SELinux User Prefix MCS Level MCS Range > SELinux Roles > > root sysadm s0 s0-s0:c0.c1023 > system_r sysadm_r staff_r > staff_u staff s0 s0-s0:c0.c1023 > sysadm_r staff_r > sysadm_u sysadm s0 s0-s0:c0.c1023 > sysadm_r > system_u user s0 s0-s0:c0.c1023 > system_r > user_u user s0 s0 > user_r > > > Question > ======== > Most of the time, when I SSH into the system as Linux User "admin", I > get a security context of "staff_u:staff_r:staff_t". Which is what I > actually want, given how I have configured policy and everything. > > While the system runs over weeks at customer sites, (don't know exactly > what sequence of events transpire on the system, but possibly does > include several reboots), SOMETIMES, given the mappings described above, > when we SSH in as "admin", we get a security context of: > > user_u:user_r:user_t ?!? This is obviously NOT desired, and causes my > strict policies to complain about things that should have ideally been > allowed as staff_t. > > In these strange situations: I have tried restarting sshd. I have tried > rebooting the system. It doesn't seem to correct the problem !! > > 1. What could be causing this change all of a sudden ? How does this > happen given the semanage mappings above ?? > 2. What can I do to force the security_context for Linux user "admin" to > be reset back to "staff_u:staff_r:staff:t" manually ? > 3.What can I do to make sure that the security context remains > staff_u:staff_r:staff_t always ! > > Any other useful pointers or things to check would be appreciated. > Thanks as always. - Check that sshd is running in the correct security context (ps -eZ or sestatus -v | grep sshd). - Check that your policy files are labeled correctly (restorecon -Rv /etc/selinux). - Use libselinux/utils/getseuser to check the result, e.g. # ./getseuser admin system_u:system_r:sshd_t:s0 seuser: staff_u, level s0 Context 0 staff_u:staff_r:staff_t:s0 Context 1 staff_u:sysadm_r:sysadm_t:s0 -- 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.
