Hi Dave, I forgot to mention that, after doing the un-tarring of the policy collection, I did run the restorecon command: restorecon -rF / restorecon -rF /etc/ And I did try running /usr/sbin/load_policy ... If I ssh in as Admin, I still get the wrong user context of staff_u:sysadm_r:sysadm_t:s0 :-( But if I reboot the machine, and then ssh in as Admin, I get the correct user context of staff_u:staff_r:staff_t !! Is there any other hidden thing that the reboot does that helps in setting the user contexts correctly ? Thanks again for all the help... -----Original Message----- From: Dave Quigley [mailto:dpquigl@xxxxxxxxxxxxx] Sent: Wednesday, January 30, 2008 6:31 PM To: Hasan Rezaul-CHR010 Cc: Stephen Smalley; SE Linux Subject: Re: Accurately setting Security Context of a user when ssh-ing in On Wed, 2008-01-30 at 19:35 -0500, Hasan Rezaul-CHR010 wrote: > Hi All, > > What file or info in the policy determines what security context a user > will get after ssh-ing in...? > > In other words, If I have a Linux_user = Admin, which is mapped to > SELinux_user = staff_u , SELinux_role = staff_r, how do I guarantee that > when I ssh in as "Admin", I will ALWAYS get the security_context = > staff_u:staff_r:staff_t > > > The reason I ask is as follows: > > I have developed a certain collection of *strict* policies on a Fedora > machine that achieve what I want. > When I ssh into this Fedora machine as "Admin", I do get the context = > staff_u:staff_r:staff_t > > So I tar up everything in the /etc/selinux/ directory, and create a > selinux_policies.tar lets say. > > Now, I untar selinux_policies.tar onto *another* machine (Machine B)! > > Then when I ssh into Machine B, with Linux account "Admin", I get > security_context = sysadm_u:sysadm_r:sysadm_t ?!? > > Weird thing is, If I reset Machine B, and *then* ssh in as "Admin", I > then get the correct security_context = staff_u:staff_r:staff_t. > > So after untarring the collection of policies (the entire > /etc/selinux/*** directory): > 1. when I ssh in as Admin, I always get the wrong security_context > 2. But if I reset the machine, and after machine comes up, if I then > ssh in as Admin, I get the correct security_context. > 3. subsequent resets, and ssh-ing in still gives me the correct > security_context... > > A. So why am I getting the wrong security_context after untarring > /etc/selinux/*** onto a target machine B. > B. And why is resetting the machine fixing this problem ? > > Hopefully the question was not too confusing ;-) > > Thanks in advance for any help. > > > > -- > 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. The reason that you are not getting the correct user and role information until you reboot is that the system is still using the old policy at that point. Even though you have untarred the new policies in place it still has the old one loaded into the kernel. You can try executing load_policy after you have untarred it to reload the policy. One thing to check on is that all the files under /etc/selinux are labeled properly. I am not sure if tar is going to retain the file labeling or not so if it doesn't you will probably have to either restorecon the directory or relabel the filesystem on reboot. Dave -- 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.
