Hi, i have tried disabling SElinux ,because i didnt had selinux module enabled in my kernel. i have tried changing /etc/selinux/config: from SELINUX=permissive to SELINUX=disabled but still i get error "Failed to load SELinux policy." during bootup
i have referred to "https://bugzilla.redhat.com/show_bug.cgi?id=692573 " and tried to solve this problem, but no positive results
also sometimes i get I/O errors on my hard disk (during boot) after one or two boots . i am not sure whether its because of SElinux or not,but while searching this I/O error i came across few cases where these I/O errors were because of SElinux policies.
other details: arch:x86 selinux version:libselinux-2.0.99-4.fc15.i686
On 23/10/12 17:12, magina antimage wrote:
Hi, i have tried disabling SElinux ,because i didnt had selinux module enabled in my kernel. i have tried changing /etc/selinux/config: from SELINUX=permissive to SELINUX=disabled but still i get error "Failed to load SELinux policy." during bootup
i have referred to "https://bugzilla.redhat.com/show_bug.cgi?id=692573 " and tried to solve this problem, but no positive results
also sometimes i get I/O errors on my hard disk (during boot) after one or two boots . i am not sure whether its because of SElinux or not,but while searching this I/O error i came across few cases where these I/O errors were because of SElinux policies.
other details: arch:x86 selinux version:libselinux-2.0.99-4.fc15.i686 -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Apart from the fact that F15 is no longer supported. This sounds like critical harddrive failure.
Run smartctl -a /dev/sdxx|grep -i failed But do not take the output for granted.
If your logs show/have shown sector errors, then the HD is probably corrupted and has taken random data with it. Of course, it could be the cables, or the controller as well.
Regards,
Tristan
On Tue, Oct 23, 2012 at 10:07 PM, Tristan Santore < tristan.santore@internexusconnect.net> wrote:
On 23/10/12 17:12, magina antimage wrote:
Hi, i have tried disabling SElinux ,because i didnt had selinux module enabled in my kernel. i have tried changing /etc/selinux/config: from SELINUX=permissive to SELINUX=disabled but still i get error "Failed to load SELinux policy." during bootup
i have referred to "https://bugzilla.redhat.com/show_bug.cgi?id=692573 " and tried to solve this problem, but no positive results
also sometimes i get I/O errors on my hard disk (during boot) after one or two boots . i am not sure whether its because of SElinux or not,but while searching this I/O error i came across few cases where these I/O errors were because of SElinux policies.
other details: arch:x86 selinux version:libselinux-2.0.99-4.fc15.i686 -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Apart from the fact that F15 is no longer supported. This sounds like critical harddrive failure.
Run smartctl -a /dev/sdxx|grep -i failed But do not take the output for granted.
If your logs show/have shown sector errors, then the HD is probably corrupted and has taken random data with it. Of course, it could be the cables, or the controller as well.
Regards,
Tristan
-- Tristan Santore BSc MBCS TS4523-RIPE Network and Infrastructure Operations InterNexusConnect Mobile +44-78-55069812 Tristan.Santore@internexusconnect.net
Former Thawte Notary (Please note: Thawte has closed its WoT programme down, and I am therefore no longer able to accredit trust)
For Fedora related issues, please email me at: TSantore@fedoraproject.org -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
thanks for replying Hmm...well thats strange because ihave formatted that same hard disk again and again,copied fedora 15 FSystem over it and booted ,and now i am not getting any I/O error. P.S -earlier i formatted HDD in ext3 format and now i am formatting in ext2,does that makes any difference??
Any idea about SElinux problem.why its showing "Failed to load SELinux policy." during bootup I think this message doesnt hurts but still i want to get rid of it, as i have disabled SElinux .
On 10/23/2012 06:12 PM, magina antimage wrote:
Hi, i have tried disabling SElinux ,because i didnt had selinux module enabled in my kernel. i have tried changing /etc/selinux/config: from SELINUX=permissive to SELINUX=disabled but still i get error "Failed to load SELinux policy." during bootup
i have referred to "https://bugzilla.redhat.com/show_bug.cgi?id=692573 " and tried to solve this problem, but no positive results
also sometimes i get I/O errors on my hard disk (during boot) after one or two boots . i am not sure whether its because of SElinux or not,but while searching this I/O error i came across few cases where these I/O errors were because of SElinux policies.
other details: arch:x86 selinux version:libselinux-2.0.99-4.fc15.i686 -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
You see the following problem on F15
https://bugzilla.redhat.com/show_bug.cgi?id=692573
Anyways you can turn SELinux back. Also you could try to use a newer Fedora version.
Regards, Miroslav
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
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
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:
- setenforce 0
- change you logging mappings to exclude unconfined_u
- purge /tmp and /var/tmp
- semodule unconfineduser
- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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:
- 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.
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:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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:
- setenforce 0 2. change you logging mappings to exclude unconfined_u
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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlD1jSkACgkQrlYvE4MpobM/lgCgpj/7c1J2ZDtoNazcScHiqm4g HQUAoIg2VCS8nqJsSa9E0gDowFH4UbeK =zUUf -----END PGP SIGNATURE-----
-----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@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:
- 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.
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:
-----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@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:
- 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. -----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-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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 .
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.
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..
Thanks, Anamitra
On 1/15/13 3:15 PM, "Daniel J Walsh" dwalsh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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 .
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlD14voACgkQrlYvE4MpobOrJQCcClbq3wIfHeg9pF/su6z2K+PB LG4An18jMjf1yyr4BfxWx1qJcY+/fBIN =Dlar -----END PGP SIGNATURE-----
-----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.
- 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
Hi Dan,
Now we are able to remove unconfined types and users successfully. But after this removal we see a whole bunch of new denials related to initrc_t as follows
#============= initrc_t ============== #!!!! The source type 'initrc_t' can write to a 'dir' of the following types: # var_log_t, ipsec_var_run_t, pam_var_run_t, ricci_var_lib_t, rpm_var_lib_t, net_conf_t, quota_flag_t, etc_runtime_t, dirsrv_var_run_t, udev_var_run_t, var_lib_nfs_t, virt_var_lib_t, mysqld_db_t, named_conf_t, initrc_tmp_t, pam_var_console_t, system_dbusd_var_lib_t, sanlock_var_run_t, cgroup_t, boot_t, cert_t, mnt_t, root_t, tmp_t, device_t, dkim_milter_data_t, etc_t, file_t, fonts_t, tmpfs_t, lockfile, pidfile, tmpfile, etc_mail_t, initrc_state_t, postgresql_db_t, alsa_etc_rw_t, gconf_etc_t, var_spool_t, xserver_log_t, virt_cache_t, var_lib_t, var_run_t, dhcpc_state_t, faillog_t, squid_log_t, core_log_t, svc_svc_t
allow initrc_t admin_home_t:dir { write remove_name }; allow initrc_t admin_home_t:file { execute unlink execute_no_trans setattr }; allow initrc_t admin_home_t:lnk_file read; allow initrc_t base_script_t:file { execute setattr read open ioctl execute_no_trans }; #!!!! The source type 'initrc_t' can write to a 'dir' of the following types: # var_log_t, ipsec_var_run_t, ricci_var_lib_t, net_conf_t, quota_flag_t, etc_runtime_t, dirsrv_var_run_t, udev_var_run_t, var_lib_nfs_t, virt_var_lib_t, mysqld_db_t, named_conf_t, initrc_tmp_t, system_dbusd_var_lib_t, sanlock_var_run_t, boot_t, cert_t, mnt_t, root_t, tmp_t, device_t, etc_t, fonts_t, tmpfs_t, lockfile, etc_mail_t, initrc_state_t, postgresql_db_t, alsa_etc_rw_t, gconf_etc_t, var_spool_t, virt_cache_t, var_lib_t, var_run_t, dhcpc_state_t, faillog_t, squid_log_t, core_log_t, svc_svc_t
allow initrc_t bin_t:dir { write add_name }; allow initrc_t bin_t:file setattr; allow initrc_t bps_log_t:dir setattr; allow initrc_t ccm_t:dir setattr; allow initrc_t ccm_t:file setattr; #!!!! The source type 'initrc_t' can write to a 'dir' of the following types: # ricci_var_lib_t, dirsrv_var_run_t, mysqld_db_t, named_conf_t, initrc_tmp_t, mnt_t, fonts_t, tmpfs_t, lockfile, initrc_state_t, virt_cache_t, var_run_t, faillog_t, svc_svc_t
allow initrc_t cisco_etc_t:dir { write remove_name add_name setattr }; #!!!! The source type 'initrc_t' can write to a 'file' of the following types: # var_log_t, initrc_var_run_t, ipsec_var_run_t, mdadm_var_run_t, ricci_var_lib_t, net_conf_t, quota_flag_t, etc_runtime_t, dirsrv_var_run_t, udev_var_run_t, var_lib_nfs_t, virt_var_lib_t, initrc_tmp_t, system_dbusd_var_lib_t, sanlock_var_run_t, boot_t, cert_t, mnt_t, device_t, fonts_t, lockfile, etc_mail_t, initrc_state_t, alsa_etc_rw_t, gconf_etc_t, var_spool_t, virt_cache_t, var_lib_t, dhcpc_state_t, faillog_t, squid_log_t, core_log_t, svc_svc_t
allow initrc_t cisco_etc_t:file { write setattr read create unlink open }; allow initrc_t cli_script_t:file setattr; allow initrc_t clm_port_t:tcp_socket name_bind; allow initrc_t clm_port_t:udp_socket name_bind; allow initrc_t cm_bin_t:file { execute setattr }; allow initrc_t cm_conf_t:dir setattr; allow initrc_t cm_conf_t:file setattr; allow initrc_t cm_lib_t:file { read execute open setattr }; allow initrc_t cm_lib_t:lnk_file read; allow initrc_t cm_locale_t:dir setattr; allow initrc_t cm_locale_t:file setattr; allow initrc_t cm_log_t:dir setattr; allow initrc_t cm_security_t:dir setattr; allow initrc_t cm_t:file setattr; allow initrc_t cm_war_t:file setattr; #!!!! The source type 'initrc_t' can write to a 'dir' of the following types: # ricci_var_lib_t, dirsrv_var_run_t, mysqld_db_t, named_conf_t, initrc_tmp_t, mnt_t, fonts_t, tmpfs_t, lockfile, initrc_state_t, virt_cache_t, var_run_t, faillog_t, svc_svc_t
allow initrc_t common_t:dir { write add_name setattr }; #!!!! The source type 'initrc_t' can write to a 'file' of the following types: # var_log_t, initrc_var_run_t, ipsec_var_run_t, mdadm_var_run_t, ricci_var_lib_t, net_conf_t, quota_flag_t, etc_runtime_t, dirsrv_var_run_t, udev_var_run_t, var_lib_nfs_t, virt_var_lib_t, initrc_tmp_t, system_dbusd_var_lib_t, sanlock_var_run_t, boot_t, cert_t, mnt_t, device_t, fonts_t, lockfile, etc_mail_t, initrc_state_t, alsa_etc_rw_t, gconf_etc_t, var_spool_t, virt_cache_t, var_lib_t, dhcpc_state_t, faillog_t, squid_log_t, core_log_t, svc_svc_t
allow initrc_t common_t:file { write ioctl setattr read create open append }; #!!!! The source type 'initrc_t' can write to a 'dir' of the following types: # var_log_t, ipsec_var_run_t, pam_var_run_t, ricci_var_lib_t, rpm_var_lib_t, net_conf_t, quota_flag_t, etc_runtime_t, dirsrv_var_run_t, udev_var_run_t, var_lib_nfs_t, virt_var_lib_t, mysqld_db_t, named_conf_t, initrc_tmp_t, pam_var_console_t, system_dbusd_var_lib_t, sanlock_var_run_t, cgroup_t, boot_t, cert_t, mnt_t, root_t, tmp_t, device_t, dkim_milter_data_t, etc_t, file_t, fonts_t, tmpfs_t, lockfile, pidfile, tmpfile, etc_mail_t, initrc_state_t, postgresql_db_t, alsa_etc_rw_t, gconf_etc_t, var_spool_t, xserver_log_t, virt_cache_t, var_lib_t, var_run_t, dhcpc_state_t, faillog_t, squid_log_t, core_log_t, svc_svc_t
allow initrc_t db_t:dir { write remove_name }; allow initrc_t db_t:file { read unlink open setattr }; allow initrc_t device_t:sock_file write; #!!!! This avc can be allowed using the boolean 'allow_ypbind'
allow initrc_t dhcpc_port_t:udp_socket name_bind; allow initrc_t dhcpd_initrc_exec_t:file setattr; allow initrc_t drf_exec_t:file setattr; allow initrc_t etc_t:dir create; allow initrc_t etc_t:file { rename write setattr create unlink append }; allow initrc_t hotplug_etc_t:file setattr; #!!!! The source type 'initrc_t' can write to a 'file' of the following types: # var_log_t, initrc_var_run_t, ipsec_var_run_t, mdadm_var_run_t, ricci_var_lib_t, net_conf_t, quota_flag_t, etc_runtime_t, dirsrv_var_run_t, udev_var_run_t, var_lib_nfs_t, virt_var_lib_t, named_conf_t, initrc_tmp_t, system_dbusd_var_lib_t, sanlock_var_run_t, boot_t, cert_t, mnt_t, wtmp_t, sysctl_type, device_t, locale_t, fonts_t, lockfile, etc_mail_t, initrc_state_t, alsa_etc_rw_t, gconf_etc_t, var_spool_t, virt_cache_t, var_lib_t, dhcpc_state_t, faillog_t, squid_log_t, core_log_t, lastlog_t, svc_svc_t
allow initrc_t hssi_t:file { write read ioctl open setattr }; #!!!! The source type 'initrc_t' can write to a 'dir' of the following types: # ricci_var_lib_t, dirsrv_var_run_t, mysqld_db_t, named_conf_t, initrc_tmp_t, boot_t, mnt_t, device_t, fonts_t, tmpfs_t, lockfile, initrc_state_t, virt_cache_t, faillog_t, svc_svc_t
allow initrc_t ibm_t:dir { write remove_name create add_name }; #!!!! The source type 'initrc_t' can write to a 'file' of the following types: # var_log_t, initrc_var_run_t, ipsec_var_run_t, mdadm_var_run_t, ricci_var_lib_t, net_conf_t, quota_flag_t, etc_runtime_t, dirsrv_var_run_t, udev_var_run_t, var_lib_nfs_t, virt_var_lib_t, initrc_tmp_t, system_dbusd_var_lib_t, sanlock_var_run_t, boot_t, cert_t, mnt_t, device_t, fonts_t, lockfile, etc_mail_t, initrc_state_t, alsa_etc_rw_t, gconf_etc_t, var_spool_t, virt_cache_t, var_lib_t, dhcpc_state_t, faillog_t, squid_log_t, core_log_t, svc_svc_t
allow initrc_t ibm_t:file { rename read lock create write unlink open append }; allow initrc_t ibm_t:sock_file create; allow initrc_t initrc_exec_t:file { rename write setattr create unlink append }; #!!!! The source type 'initrc_t' can write to a 'fifo_file' of the following types: # initrc_state_t, svc_svc_t
allow initrc_t initrc_tmp_t:fifo_file { write read create open }; allow initrc_t install_bin_t:file { execute setattr read open ioctl execute_no_trans }; #!!!! The source type 'initrc_t' can write to a 'dir' of the following types: # var_log_t, ipsec_var_run_t, pam_var_run_t, ricci_var_lib_t, rpm_var_lib_t, net_conf_t, quota_flag_t, etc_runtime_t, dirsrv_var_run_t, udev_var_run_t, var_lib_nfs_t, virt_var_lib_t, mysqld_db_t, named_conf_t, initrc_tmp_t, pam_var_console_t, system_dbusd_var_lib_t, sanlock_var_run_t, cgroup_t, boot_t, cert_t, mnt_t, root_t, tmp_t, device_t, dkim_milter_data_t, etc_t, file_t, fonts_t, tmpfs_t, lockfile, pidfile, tmpfile, etc_mail_t, initrc_state_t, postgresql_db_t, alsa_etc_rw_t, gconf_etc_t, var_spool_t, xserver_log_t, virt_cache_t, var_lib_t, var_run_t, dhcpc_state_t, faillog_t, squid_log_t, core_log_t, svc_svc_t
allow initrc_t install_t:dir { write remove_name }; allow initrc_t install_t:file unlink; allow initrc_t ipprefsd_exec_t:file setattr; allow initrc_t ipsec_exec_t:file setattr; #!!!! The source type 'initrc_t' can write to a 'dir' of the following types: # ricci_var_lib_t, dirsrv_var_run_t, mysqld_db_t, named_conf_t, initrc_tmp_t, mnt_t, fonts_t, tmpfs_t, lockfile, initrc_state_t, virt_cache_t, var_run_t, faillog_t, svc_svc_t
allow initrc_t java_jdk_t:dir { write remove_name setattr }; allow initrc_t java_jdk_t:file { unlink setattr }; allow initrc_t java_jdk_t:lnk_file read; allow initrc_t kdump_etc_t:file setattr; allow initrc_t kdump_initrc_exec_t:file setattr; allow initrc_t ntpd_log_t:file setattr; #!!!! The source type 'initrc_t' can write to a 'dir' of the following types: # var_log_t, ipsec_var_run_t, pam_var_run_t, ricci_var_lib_t, rpm_var_lib_t, net_conf_t, quota_flag_t, etc_runtime_t, dirsrv_var_run_t, udev_var_run_t, var_lib_nfs_t, virt_var_lib_t, mysqld_db_t, named_conf_t, initrc_tmp_t, pam_var_console_t, system_dbusd_var_lib_t, sanlock_var_run_t, cgroup_t, boot_t, cert_t, mnt_t, root_t, tmp_t, var_t, device_t, dkim_milter_data_t, etc_t, file_t, fonts_t, tmpfs_t, lockfile, pidfile, tmpfile, etc_mail_t, initrc_state_t, postgresql_db_t, alsa_etc_rw_t, gconf_etc_t, var_spool_t, xserver_log_t, virt_cache_t, var_lib_t, var_run_t, dhcpc_state_t, faillog_t, squid_log_t, core_log_t, svc_svc_t
allow initrc_t opt_ibm_t:dir write; allow initrc_t opt_ibm_t:file { read execute open execute_no_trans }; allow initrc_t opt_ibm_t:lnk_file read; allow initrc_t os_service_t:file { read execute open ioctl execute_no_trans }; allow initrc_t os_t:file setattr; allow initrc_t plat_bin_t:file { execute setattr read open ioctl execute_no_trans }; #!!!! The source type 'initrc_t' can write to a 'dir' of the following types: # var_log_t, ipsec_var_run_t, ricci_var_lib_t, net_conf_t, quota_flag_t, etc_runtime_t, dirsrv_var_run_t, udev_var_run_t, var_lib_nfs_t, virt_var_lib_t, mysqld_db_t, named_conf_t, initrc_tmp_t, system_dbusd_var_lib_t, sanlock_var_run_t, boot_t, cert_t, mnt_t, root_t, tmp_t, device_t, etc_t, fonts_t, tmpfs_t, lockfile, etc_mail_t, initrc_state_t, postgresql_db_t, alsa_etc_rw_t, gconf_etc_t, var_spool_t, virt_cache_t, var_lib_t, var_run_t, dhcpc_state_t, faillog_t, squid_log_t, core_log_t, svc_svc_t
allow initrc_t plat_conf_t:dir { write add_name }; #!!!! The source type 'initrc_t' can write to a 'file' of the following types: # var_log_t, initrc_var_run_t, ipsec_var_run_t, mdadm_var_run_t, ricci_var_lib_t, net_conf_t, quota_flag_t, etc_runtime_t, dirsrv_var_run_t, udev_var_run_t, var_lib_nfs_t, virt_var_lib_t, initrc_tmp_t, system_dbusd_var_lib_t, sanlock_var_run_t, boot_t, cert_t, mnt_t, device_t, fonts_t, lockfile, etc_mail_t, initrc_state_t, alsa_etc_rw_t, gconf_etc_t, var_spool_t, virt_cache_t, var_lib_t, dhcpc_state_t, faillog_t, squid_log_t, core_log_t, svc_svc_t
allow initrc_t plat_conf_t:file { write ioctl setattr read lock create open }; allow initrc_t plat_conf_t:sock_file { write create }; allow initrc_t plat_jar_t:file setattr; allow initrc_t plat_lib_t:file { read execute open }; allow initrc_t plat_lib_t:lnk_file read; allow initrc_t plat_log_t:dir setattr; allow initrc_t plat_log_t:file { write setattr }; allow initrc_t plat_script_t:file setattr; allow initrc_t plat_script_t:lnk_file read; #!!!! The source type 'initrc_t' can write to a 'dir' of the following types: # var_log_t, ipsec_var_run_t, pam_var_run_t, ricci_var_lib_t, rpm_var_lib_t, net_conf_t, quota_flag_t, etc_runtime_t, dirsrv_var_run_t, udev_var_run_t, var_lib_nfs_t, virt_var_lib_t, mysqld_db_t, named_conf_t, initrc_tmp_t, pam_var_console_t, system_dbusd_var_lib_t, sanlock_var_run_t, cgroup_t, boot_t, cert_t, mnt_t, root_t, tmp_t, device_t, dkim_milter_data_t, etc_t, file_t, fonts_t, tmpfs_t, lockfile, pidfile, tmpfile, etc_mail_t, initrc_state_t, postgresql_db_t, alsa_etc_rw_t, gconf_etc_t, var_spool_t, xserver_log_t, virt_cache_t, var_lib_t, var_run_t, dhcpc_state_t, faillog_t, squid_log_t, core_log_t, svc_svc_t
allow initrc_t plat_t:dir { write remove_name }; allow initrc_t plat_t:file unlink; allow initrc_t plugins_bin_t:file setattr; #!!!! This avc can be allowed using the boolean 'allow_ypbind'
allow initrc_t port_t:tcp_socket name_bind; allow initrc_t repository_port_t:tcp_socket name_bind; allow initrc_t reserved_port_t:tcp_socket name_bind; allow initrc_t reserved_port_t:udp_socket name_bind; allow initrc_t rpm_script_tmp_t:file setattr; allow initrc_t rpm_tmp_t:file setattr; allow initrc_t security_t:file setattr; allow initrc_t security_t:security compute_av; allow initrc_t self:unix_dgram_socket sendto; allow initrc_t servm_exec_t:file setattr; allow initrc_t setroubleshoot_var_log_t:file setattr; allow initrc_t snmp_exec_t:file setattr; allow initrc_t snmp_script_t:file setattr; #!!!! The source type 'initrc_t' can write to a 'dir' of the following types: # var_log_t, ipsec_var_run_t, ricci_var_lib_t, net_conf_t, quota_flag_t, etc_runtime_t, dirsrv_var_run_t, udev_var_run_t, var_lib_nfs_t, virt_var_lib_t, mysqld_db_t, named_conf_t, initrc_tmp_t, system_dbusd_var_lib_t, sanlock_var_run_t, boot_t, cert_t, mnt_t, root_t, tmp_t, device_t, etc_t, fonts_t, tmpfs_t, lockfile, etc_mail_t, initrc_state_t, postgresql_db_t, alsa_etc_rw_t, gconf_etc_t, var_spool_t, virt_cache_t, var_lib_t, var_run_t, dhcpc_state_t, faillog_t, squid_log_t, core_log_t, svc_svc_t
allow initrc_t snmp_t:dir { write remove_name add_name }; #!!!! The source type 'initrc_t' can write to a 'file' of the following types: # var_log_t, initrc_var_run_t, ipsec_var_run_t, mdadm_var_run_t, ricci_var_lib_t, net_conf_t, quota_flag_t, etc_runtime_t, dirsrv_var_run_t, udev_var_run_t, var_lib_nfs_t, virt_var_lib_t, initrc_tmp_t, system_dbusd_var_lib_t, sanlock_var_run_t, boot_t, cert_t, mnt_t, device_t, fonts_t, lockfile, etc_mail_t, initrc_state_t, alsa_etc_rw_t, gconf_etc_t, var_spool_t, virt_cache_t, var_lib_t, dhcpc_state_t, faillog_t, squid_log_t, core_log_t, svc_svc_t
allow initrc_t snmp_t:file { rename setattr read create write ioctl unlink open }; allow initrc_t snmpd_initrc_exec_t:file { write rename create unlink setattr }; allow initrc_t ssh_home_t:dir setattr; #!!!! The source type 'initrc_t' can write to a 'file' of the following types: # var_log_t, initrc_var_run_t, ipsec_var_run_t, mdadm_var_run_t, ricci_var_lib_t, net_conf_t, quota_flag_t, etc_runtime_t, dirsrv_var_run_t, udev_var_run_t, var_lib_nfs_t, virt_var_lib_t, named_conf_t, initrc_tmp_t, system_dbusd_var_lib_t, sanlock_var_run_t, boot_t, cert_t, mnt_t, wtmp_t, sysctl_type, device_t, locale_t, fonts_t, lockfile, etc_mail_t, initrc_state_t, alsa_etc_rw_t, gconf_etc_t, var_spool_t, virt_cache_t, var_lib_t, dhcpc_state_t, faillog_t, squid_log_t, core_log_t, lastlog_t, svc_svc_t
allow initrc_t ssh_home_t:file { read write open setattr }; allow initrc_t sshd_initrc_exec_t:file setattr; allow initrc_t syslog_conf_t:file { read ioctl open setattr }; allow initrc_t sysstat_log_t:file setattr; allow initrc_t system_conf_t:file { write append }; allow initrc_t system_cron_spool_t:file setattr; allow initrc_t taps_log_t:dir setattr; allow initrc_t tmp_t:dir setattr; #!!!! The source type 'initrc_t' can write to a 'file' of the following types: # var_log_t, initrc_var_run_t, ipsec_var_run_t, mdadm_var_run_t, ricci_var_lib_t, net_conf_t, quota_flag_t, etc_runtime_t, dirsrv_var_run_t, udev_var_run_t, var_lib_nfs_t, virt_var_lib_t, named_conf_t, initrc_tmp_t, system_dbusd_var_lib_t, sanlock_var_run_t, boot_t, cert_t, mnt_t, wtmp_t, sysctl_type, device_t, locale_t, fonts_t, lockfile, etc_mail_t, initrc_state_t, alsa_etc_rw_t, mysqld_log_t, gconf_etc_t, var_spool_t, virt_cache_t, var_lib_t, dhcpc_state_t, faillog_t, squid_log_t, core_log_t, lastlog_t, svc_svc_t
allow initrc_t tmp_t:file { write open setattr }; allow initrc_t tmp_t:sock_file { write create setattr }; allow initrc_t tomcat_exec_t:file setattr; allow initrc_t tomcat_log_t:dir setattr; #!!!! The source type 'initrc_t' can write to a 'file' of the following types: # var_log_t, initrc_var_run_t, ipsec_var_run_t, mdadm_var_run_t, ricci_var_lib_t, net_conf_t, quota_flag_t, etc_runtime_t, dirsrv_var_run_t, udev_var_run_t, var_lib_nfs_t, virt_var_lib_t, named_conf_t, initrc_tmp_t, system_dbusd_var_lib_t, sanlock_var_run_t, boot_t, cert_t, mnt_t, wtmp_t, sysctl_type, device_t, locale_t, fonts_t, lockfile, etc_mail_t, initrc_state_t, alsa_etc_rw_t, mysqld_log_t, gconf_etc_t, var_spool_t, virt_cache_t, var_lib_t, dhcpc_state_t, faillog_t, squid_log_t, core_log_t, lastlog_t, svc_svc_t
allow initrc_t tomcat_tmp_t:file { write open setattr }; allow initrc_t upgrade_exec_t:file setattr; allow initrc_t user_home_dir_t:dir setattr; allow initrc_t user_home_t:dir setattr; allow initrc_t user_home_t:file setattr; #!!!! The source type 'initrc_t' can write to a 'dir' of the following types: # ricci_var_lib_t, dirsrv_var_run_t, mysqld_db_t, named_conf_t, initrc_tmp_t, mnt_t, fonts_t, tmpfs_t, lockfile, initrc_state_t, virt_cache_t, faillog_t, svc_svc_t
allow initrc_t usr_t:dir { write remove_name create rmdir add_name }; allow initrc_t usr_t:file unlink; allow initrc_t var_log_t:dir setattr; allow initrc_t var_log_t:lnk_file read; allow initrc_t var_t:dir { remove_name create add_name rmdir }; allow initrc_t var_t:file { read create open setattr append };
Is this expected .. Is there an easy way to address these denials other than writing individual policies for the allow rules
Thanks, Anamitra
On 1/16/13 12:33 PM, "Daniel J Walsh" dwalsh@redhat.com wrote:
-----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.
- 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
-----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-----
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:
-----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.
- 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
-----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-----
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:
-----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.
- 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
-----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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
-----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
Hi Dan/Dominick,
What is the major difference between unconfined and unconfineduser policy modules in RHEL6. And if we wanted to remove the unconfined domains would it be enough to just remove the module Unconfined.
Thanks, Anamitra
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/15/2013 03:57 PM, Anamitra Dutta Majumdar (anmajumd) wrote:
Hi Dan/Dominick,
What is the major difference between unconfined and unconfineduser policy modules in RHEL6. And if we wanted to remove the unconfined domains would it be enough to just remove the module Unconfined.
Thanks, Anamitra
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
http://danwalsh.livejournal.com/42394.html
unconfineduser basically controlls unconfined_t while unconfined, allows domains like initrc_t and friends to be unconfined.
I disable unconfined but leave unconfineduser, since I believe the sysadmin_t is not that valuable from a security point of view.
I login as staff_t and transition to unconfined_t when I run sudo.
selinux@lists.fedoraproject.org