Re: Removing unconfined type

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

 



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/30/2013 07:26 PM, Radha Venkatesh (radvenka) wrote:
> 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:
> 
> 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
>>>> 
> 
> 
> -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx 
> https://admin.fedoraproject.org/mailman/listinfo/selinux -- selinux mailing
> list selinux@xxxxxxxxxxxxxxxxxxxxxxx 
> https://admin.fedoraproject.org/mailman/listinfo/selinux
> 

Is this on RHEL6?

One trick would be to alias java_t to unconfined_java_t

typealias java_t alias unconfined_java_t;

But I would think it would be better to just get rid of java_exec_t.

We have removed it from RHEL7 and all Fedoras.

Maybe you could disable the java.pp

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlH4/JUACgkQrlYvE4MpobP34gCgoSKQWthsPPcHBj7+aQAXjve4
YbQAoMsgOHu/WTDFUFUywk1BZYtd4N9x
=NDkV
-----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