Re: Removing unconfined type

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----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



[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux