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@xxxxxxxxxxxxxxxxxxxxxxx [mailto:selinux-bounces@xxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Anamitra Dutta Majumdar (anmajumd)
Sent: Tuesday, February 19, 2013 9:17 PM
To: Daniel J Walsh
Cc: selinux@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxx> 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.
>>
>> 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
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
