-----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.
- 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.
- 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@redhat.com 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@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 .
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux