"Could you answer me the question why most of the daemons started by init running in initrc_t and not unconfined_t. ok, I understand how transition form init_t, initrc_exec_t to initrc_t works. but I don't understand why they are not running unconfined_t, when they don't have a own policy. what are the permissions for initrc_t. are they comparable to unconfined_t? "
One of the interesting things about Targeted policy is the existence of the unconfined domain. In the early days of porting SELinux to FC2, we quickly realized that we could not possible write policy for all situations, and SELinux would fail in the mainstream if most applications would not work out of the box. People configured their home directories in multiple different ways and ran hundreds of different applications that needed access that we could not anticipate. But SELinux is a "Deny everything by default" platform, So we needed a way to say for this process or this login session, we want it to run like SELinux is not even running on the system.
The unconfined_domain was born. This domain basically gets complete access, up to now, to the system, governed by DAC. Programs running in an unconfined_domain, should run the same as if SELinux was not defined Unconfined domains to however have transition rules. Domains transition rules that say if unconfined domain ABC_T runs applications labeled XYZ_exec_t will transition to XYZ_t. File transition rules that say if unconfined domain ABC_t creates a file in DEF_T it will create GHI_T. The most obvious unconfined_domain in SELinux is unconfined_t. This is the default login domain for users on an SELinux box. This is a userdomain, and should only be on processes created by a logged in user.
Another common unconfined_domain is initrc_t. The idea here was when init starts an application that does not have a policy defined (Is not a target), this application needs to be able to run. So the application continues to run in initrc_t and can do everything it could do with SELinux disabled. This is different from strict policy where the application would fail and the administrator would be forced to write policy for his application. So when the machines boots up it starts the init process as init_t, also an unconfined domain. When this process runs scripts or programs labeled initrc_exec_t, they run as initrc_t. When initrc_t runs a binary labeled as a targeted domain say named_exec_t, the application transitions to named_t.
The main different between initrc_t and unconfined_t is the transition rules. For example httpd transitions from initrc_t to httpd_t, while it does not transition from unconfined_t. There are also some differences in file_trans. So initrc_t creating a file in /etc/ gets transitioned to etc_runtime_t, while unconfined_t stays as etc_t.
There is a transition from unconfined_t -> initrc_exec_t -> initrc_t.
This allows unconfined_t users to run service httpd start, and the correct thing happens.
There are a few unconfined domains in a targeted policy, the main reason for this is different transition rules. As was stated in previous blogs, we have started added some confinement to the unconfined_domains, in the form of executable memory checking. This has led to a few new domains. For example we may want to turn off execstack for most of the unconfined domain, but java applications by design need this access. So an unconfined_domain java_t was added to java apps with no policy defined.
In FC7 we are hoping to add booleans to allow sysadmins to toggle applications from unconfined_t to confined_t. So an admin that runs only targeted daemons on his system could turn off initrc_t ability to run unconfined.
If you are building a reference policy module and you only want transition rules but want the application to run unconfined you would use the unconfined_domain() interface.