-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/16/2013 01:28 PM, Anamitra Dutta Majumdar (anmajumd) wrote: > Hi Dan, > > I have a couple of more follow up questions. > > 1. What we have seen on our systems is just running restorecon -R does not > fix the issue. We need to run restore -R -F to force the pick of file > contexts. So it seems that the -F options does more things that just -R. Is > that a correct understanding. > Yes -F will fix the User/role/mls fields as well as the type field, without the -F, restorecon only fixes the type field. > 2. After removing the unconfined types and users and doing restorecon we > see that root still is mapped to unconfined_u > > root unconfined_u s0-s0:c0.c1023 > > Do we need to change this mapping as well. And if we do would it have any > adverse effect on the system.. > No this should be changed to sysadm_u. Which will cause your root account to login as sysadm_t. You might have to turn on a couple of booleans to allow sysadm_t to login directly ssh_sysadm_login --> off xdm_sysadm_login --> off > Thanks, Anamitra > > > > On 1/15/13 3:15 PM, "Daniel J Walsh" <dwalsh@xxxxxxxxxx> wrote: > > On 01/15/2013 06:07 PM, Anamitra Dutta Majumdar (anmajumd) wrote: >>>> Hi Dan, >>>> >>>> We have removed the unconfined_u user type .We do not see it when we >>>> do a semanage user -l >>>> >>>> [root@vos-cm148 home]# semanage user -l >>>> >>>> Labeling MLS/ MLS/ SELinux User Prefix MCS Level MCS >>>> Range SELinux Roles >>>> >>>> admin_u user s0 s0-s0:c0.c1023 sysadm_r >>>> system_r git_shell_u user s0 s0 git_shell_r >>>> guest_u user s0 s0 guest_r root user s0 >>>> s0-s0:c0.c1023 sysadm_r system_r specialuser_u user s0 >>>> s0 sysadm_r system_r staff_u user s0 >>>> s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r sysadm_u >>>> user s0 s0-s0:c0.c1023 sysadm_r system_u user s0 >>>> s0-s0:c0.c1023 system_r unconfined_r user_u user s0 s0 >>>> user_r xguest_u user s0 s0 xguest_r >>>> >>>> >>>> >>>> But some file security contexts still have unconfined_u >>>> >>>> drwxr-xr-x. root root system_u:object_r:home_root_t:s0 >>>> . dr-xr-xr-x. root root system_u:object_r:root_t:s0 .. >>>> drwx------. admin administrator >>>> user_u:object_r:user_home_dir_t:s0 admin drwxr-x---. ccmservice >>>> ccmbase unconfined_u:object_r:user_home_dir_t:s0 ccmservice >>>> drwx------. drfkeys drfkeys unconfined_u:object_r:user_home_dir_t:s0 >>>> drfkeys drwxr-x---. drfuser platform >>>> unconfined_u:object_r:user_home_dir_t:s0 drfuser drwxr-xr-x. informix >>>> informix system_u:object_r:user_home_dir_t:s0 informix drwx------. >>>> pwrecovery platform unconfined_u:object_r:user_home_dir_t:s0 >>>> pwrecovery drwxr-x---. sftpuser sftpuser >>>> unconfined_u:object_r:user_home_dir_t:s0 sftpuser drwxr-x---. tomcat >>>> tomcat unconfined_u:object_r:tomcat_t:s0 tomcat >>>> >>>> >>>> What would be the reason for that? >>>> >>>> >>>> Thanks, Anamitra >>>> >>>> On 1/15/13 9:22 AM, "Daniel J Walsh" <dwalsh@xxxxxxxxxx> wrote: >>>> >>>> On 01/15/2013 12:19 PM, Anamitra Dutta Majumdar (anmajumd) wrote: >>>>>>> Hi Dan, >>>>>>> >>>>>>> Thanks for the prompt response. >>>>>>> >>>>>>> The reason I brought this thread alive is because I see a lot >>>>>>> of denials after removing the unconfined type and doing a >>>>>>> fixfiles && reboot and as you indicated They are many resources >>>>>>> that have acquired unlabeled_t and hence we see a lot of >>>>>>> denials. So based on this I would like to ask when exactly >>>>>>> should we have the reboot after executing fixfiles. Should the >>>>>>> reboot be immediate after we have removed the unconfined type >>>>>>> or can it wait for a later time. >>>>>>> >>>>>>> Thanks, Anamitra >>>>>>> >>>>>>> On 1/15/13 9:08 AM, "Daniel J Walsh" <dwalsh@xxxxxxxxxx> >>>>>>> wrote: >>>>>>> >>>>>>> On 01/15/2013 11:48 AM, Anamitra Dutta Majumdar (anmajumd) >>>>>>> wrote: >>>>>>>>>> Hi Dominick, >>>>>>>>>> >>>>>>>>>> Can you help me understand why step 5 is needed. >>>>>>>>>> >>>>>>>>>> Thanks, Anamitra >>>>>>>>>> >>>>>>>>>> On 10/30/12 1:03 PM, "Dominick Grift" >>>>>>>>>> <dominick.grift@xxxxxxxxx> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, 2012-10-30 at 19:45 +0000, Anamitra Dutta >>>>>>>>>>> Majumdar (anmajumd) wrote: >>>>>>>>>>>> We are on RHEL6 and we need to remove the unconfined >>>>>>>>>>>> type from our targeted Selinux policies so that no >>>>>>>>>>>> process runs in the unconfined domain. >>>>>>>>>>>> >>>>>>>>>>>> In order to achieve that we have removed the >>>>>>>>>>>> unconfined module .Is there anything Else we need to >>>>>>>>>>>> do. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, Anamitra >>>>>>>>>>> >>>>>>>>>>> You can also disable the unconfineduser module to make >>>>>>>>>>> it even more strict >>>>>>>>>>> >>>>>>>>>>> but if you do make sure that no users are mapped to >>>>>>>>>>> unconfined_u and relabel the file system because >>>>>>>>>>> selinux will change contexts that have unconfined_u in >>>>>>>>>>> them to unlabeled_t is unconfined_u no longer exists >>>>>>>>>>> >>>>>>>>>>> so in theory: >>>>>>>>>>> >>>>>>>>>>> 1. setenforce 0 2. change you logging mappings to >>>>>>>>>>> exclude unconfined_u 3. purge /tmp and /var/tmp 4. >>>>>>>>>>> semodule unconfineduser 5. fixfiles onboot && reboot >>>>>>>>>>> >>>>>>>>>>> I think that should take care of it >>>>>>>>>>> >>>>>>>>>>> Not though that even then there will be some >>>>>>>>>>> unconfined domains left >>>>>>>>>>> >>>>>>>>>>> There is no way to get them out without manually >>>>>>>>>>> editing and rebuilding the policy >>>>>>>>>>> >>>>>>>>>>> But if you disabled the unconfined and unconfineduser >>>>>>>>>>> modules then you are running pretty strict >>>>>>>>>>> >>>>>>>>>>>> -- selinux mailing list >>>>>>>>>>>> selinux@xxxxxxxxxxxxxxxxxxxxxxx >>>>>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> - -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx >>>>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> - -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx >>>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux >>>>>>>>>> >>>>>>> If you have any files that are owned by unconfined_u they will >>>>>>> become unlabeled_t and not able to be used by confined domains, >>>>>>> which is why the relabel is required. >>>>>>> >>>> >>>> If you have any processes running on your system that are >>>> unconfined_t then they will become unlabled_t and start generating >>>> AVC's. Any confined apps that are trying to read unlabeled_u files >>>> will start to fail also. >>>> >>>> It is probably best to do this at Single User mode/permissive and >>>> then cleanup the disk. >>>> >>>> -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx >>>> https://admin.fedoraproject.org/mailman/listinfo/selinux >>>> > > Because you have not relabeled them. > > restorecon -R -F -v . > > > -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/selinux > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlD3DqYACgkQrlYvE4MpobOaVwCgshodynIrPestWf404bmGVzHf h7QAnjYKPUofQmgB7fKqMFo7p6Tuy4kn =Lk07 -----END PGP SIGNATURE----- -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
