-----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(a)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(a)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(a)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.
>>>
>>> 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(a)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(a)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(a)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(a)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(a)lists.fedoraproject.org
>>>>>>>>>>>>>>
https://admin.fedoraproject.org/mailman/listinfo/selinux
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
- -- selinux mailing list
selinux(a)lists.fedoraproject.org
>>>>>>>>>>>>>
https://admin.fedoraproject.org/mailman/listinfo/selinux
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
- -- selinux mailing list
selinux(a)lists.fedoraproject.org
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(a)lists.fedoraproject.org
>>>>>>
https://admin.fedoraproject.org/mailman/listinfo/selinux
>>>>>>
>>>
>>> Because you have not relabeled them.
>>>
>>> restorecon -R -F -v .
>>>
>>>
>>> -- selinux mailing list selinux(a)lists.fedoraproject.org
>>>
https://admin.fedoraproject.org/mailman/listinfo/selinux
>>>
-- selinux mailing list selinux(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux -- selinux mailing
list selinux(a)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
-----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-----