Removing unconfined type

Tue Jan 15 23:07:09 UTC 2013

Hi Dan,

We have removed the unconfined_u user type .We do not see it when we do a
semanage user -l

[root at 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 at redhat.com> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>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 at 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 at 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 at lists.fedoraproject.org
>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>>>>>> 
>>>>>> 
>>>>>> -- selinux mailing list selinux at lists.fedoraproject.org
>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>>>>> 
>>>>> -- selinux mailing list selinux at 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.
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.13 (GNU/Linux)
>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
>iEYEARECAAYFAlD1kD8ACgkQrlYvE4MpobMgpwCfdh76bmMo/JeP0sljxv0pGxyo
>UJwAn0kE9Dde3tmy/gQPinhyu/e+JO5P
>=PsFL
>-----END PGP SIGNATURE-----