I was on the phone with a customer the other day who was setting up a web site and he was using strict policy on Red Hat Enterprise Linux 5. He was having problems getting sudo to run from a cgi script. When I asked him which policy he was running he told me strict. I informed him that in order to get support for strict policy you are supposed to have a special support contract with Red Hat. He told me that he was worried that targeted policy was not as secure a "strict". Arrrrrrrggggggg. They are the same, from an Apache point of view. Both Strict and Targeted policy in RHEL5 support around 200 confined domains. Pretty much all of system space is confined. Targeted policy is used by hundreds of thousands or machines, stict on maybe hundreds, so guess which one runs better?
The two major differences in RHEL5 is strict policy confined logged in users, NOT ADMINS. If you have an server machine that only an admin is going to login to you do not want/need to use strict policy.
Most admins are not confined, and will probably need to be able to execute setenforce 0 or install rpm packages, so attempting to confine them is somewhat fruitless
As far as unconfined domains, The three most common on a targeted machine are
- unconfined_t, default user login.
- java_t, mono_t, unconfined_execmem_t, are additional versions of the unconfined_t login
- initrc_t - default policy for services started by /etc/init.d/ scripts
- This allows any third party software that does not have a policy to run
- inetd_t - default policy for services run in /etc/xinetd/
- inetd_child_t is another form of this domain
Luckily Strict policy disappears with the advent of Fedora 9. In Fedora 9 you can run confined users and unconfined users at the same time. You you remove the unconfined.pp policy module, you will remove the ability to run unconfined domains. So I will not need to worry about policy "naming" in the Future.