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.
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..
Thanks, Anamitra
On 1/15/13 3:15 PM, "Daniel J Walsh" dwalsh@redhat.com wrote:
-----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@redhat.com 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@redhat.com 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@gmail.com 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@lists.fedoraproject.org >>>> https://admin.fedoraproject.org/mailman/listinfo/selinux >>> >>> >>> -- selinux mailing list selinux@lists.fedoraproject.org >>> https://admin.fedoraproject.org/mailman/listinfo/selinux >> >> -- selinux mailing list selinux@lists.fedoraproject.org >> 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@lists.fedoraproject.org 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-----