Dan,
We were able to successfully remove the unconfined type and user. However, in a very particular scenario, we are still seeing denials related to unconfined_java_t. How do we remove this type from our system and what would be the side effects of this removal.
These are the denials we saw:
type=AVC msg=audit(1375225734.281:32716): avc: denied { rlimitinh } for pid=9566 comm="java" scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:system_r:unconfined_java_t:s0 tclass=process type=AVC msg=audit(1375225734.281:32716): avc: denied { noatsecure } for pid=9566 comm="java" scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:system_r:unconfined_java_t:s0 tclass=process
We tried to force a domain transition from initrc_t to java_t when executing java_exec_t but it threw the following error
libsepol.expand_terule_helper: conflicting TE rule for (initrc_t, java_exec_t:process): old was unconfined_java_t, new is java_t libsepol.expand_module: Error during expand libsemanage.semanage_expand_sandbox: Expand module failed semodule: Failed!
Could you please suggest next steps?
Thanks, radha
-----Original Message----- From: selinux-bounces@lists.fedoraproject.org [mailto:selinux-bounces@lists.fedoraproject.org] On Behalf Of Anamitra Dutta Majumdar (anmajumd) Sent: Tuesday, February 19, 2013 9:17 PM To: Daniel J Walsh Cc: selinux@lists.fedoraproject.org Subject: Re: Removing unconfined type
Hi Dan,
In the last email you suggested that we beed to change the mapping from unconfined_u selinux user to sysadm_u selinux user for root login.
Why should this not be root selinux user instead of sysadm_u.
On RHEL5 system which has strict policies loaded we see the following..
[root@vos-cm127 ~]# semanage login -l
root root SystemLow-SystemHigh
Root is mapped to root selinux user. Can we keep it that way in the RHEL6 systems as well
Thanks, Anamitra
On 1/16/13 12:33 PM, "Daniel J Walsh" dwalsh@redhat.com wrote:
-----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
-----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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux