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.