-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 . -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlD14voACgkQrlYvE4MpobOrJQCcClbq3wIfHeg9pF/su6z2K+PB LG4An18jMjf1yyr4BfxWx1qJcY+/fBIN =Dlar -----END PGP SIGNATURE----- -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
