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