First lets talk about the boot process.
When the SELinux kernel boots up it is hard coded to run as kernel_t. Since at this point there is no policy running, this is the only context. So since this is the only context all applications that are run will stay in kernel_t. When the kernel executes /sbin/init it originally is running as kernel_t, then it reads in the policy file and loads it into the kernel. At this point init re-execs itself. When /sbin/init was installed is labeled init_exec_t and now there is a rule in the kernel that says when kernel_t execs an application labeled init_exec_t, it should transition to init_t. So now the init process is running as init_t.
The init process then runs /etc/rc.d/rc.sysinit which is labeled initrc_exec_t. The kernel has a rule that says when init_r execs initrc_exec_t it transitions to initrc_t. So this continues until the httpd executable gets started as httpd_t.
The kernel will now examine every access (read) of the process domain (httpd_t) on the class (file) of objects on the system /var/www/index.html (httpd_sys_content_t). If there is a rule in policy that allows it the access will go forward. If it is denied, an AVC, Access Vector Cache, message will be generated in the log file. By the way don't blame me for AVC, I was not the one who chose the name.
What about unconfined_t and the login process?
Certain Applications, such as login, are allowed by policy to set the context of the next executed program.
Actually most of the login programs are using pam_selinux to get this behavior.
So when I log in to the system. pam users libselinux to figure out what is the initial context setup for username dwalsh? On a targeted system this will be unconfined_t. You can modify this behavior by changing files in /etc/selinux/POLICYTYPE/contexts/default
So once the user is logged his shell will be running with unconfined_t or user_t, every access that the user makes is going through the kernel to make sure the access is allowed. Obviously this is all cached to make the overhead as little as possible.
NOTE:
One curious thing that you might have noticed, is depending on how you start an application, it could end up running in a different context. For example if I run httpd via the service start up script it will run as httpd_t, but if I run it directly it will run as unconfined_t.
Why????
There is a rule in the kernel that says unconfined_t running initrc_exec_t will transition to initrc_t, and initrc_t running httpd_exec_t will transition to httpd_t. There is also a rule that says unconfined_t is allow to run httpd_exec_t without transitioning.
This was a conscious decision made by the policy writers to attempt to lesson confusion. You see most confined domains are not allowed to talk to the terminal. They are also not allowed to read/write users home directories. The reason for this is we are trying to protect user space from system space, and if a hacked targeted domain was able to read/write the console or terminal, it could put up a login screen and us lemmings would just enter our username and password. Similarly if a targeted domain was able to read/write our homedirs it could read our credit card data, modify our login scripts, or generally cause havoc.
So one problem with this is administrators sometimes run the targeted domain with --help or want to test a cgi script and they would see no output. Or would attempt to redirect the output to their home directories.
./mycgi_script >> ~dwalsh.out
If these domains transitioned, these access would be denied, and the user would have a hard time understand what happened.
So if you want to run a targeted domain under the locked down context, you need to use the init scripts.
Tomorrow:
Key components of SELinux: Applications

shouldn't the init_r here really mean init_t according to what you said above?
that's another little mistake, 'pam uses libselinux to ...'.
but this is a wonderful article.
i wish you have more time to write more wonderful articles.
thanks dan walsh!
problem with unconfined_t
I have written a program which access a file;and i have given a context system_u:object_r:app_exec_t. Domain is app_t.
But no where permission give to unconfined_t, to execute the program with context app_exec_t.
Now if i run a program in root (unconfined_u:unconfined_r:unconfined_t)
ps -axZ | grep app its running with context
unconfined_u:unconfined_r:unconfined_t
Here why selinux is not blocking unconfned_t to execute app.
Please give me some idea to block this unconfined_t.
Thanks
Re: problem with unconfined_t
unconfined is allowed to execute any file_type, (app_exec_t) within it's own domain.
If you want to confine a user, you need to use confined users like staff_t and user_t.
Re: problem with unconfined_t
Thank you very much.Now i am trying with user_t but selinux is blocking some application, which i need. Now i explicitly have to give all permission ...
Thank for the support
Shrikanta
Re: problem with unconfined_t
I am using redhat 5 in that i did not find staff_t or user_t;by default its showing only unconfined_t type. Do i need download some rpm which gives staff_t or user_t ? or redhat will not support these type?.
Fedora all these types are by default, my code is working fine there.
Thank you
Re: problem with unconfined_t
You could install selinux-policy-strict and switch to strict policy but you had better know what you are doing, since you will loose the unconfined_t domain.
Re: problem with unconfined_t
trying to add new user in RHEL 5.4
As there is no user_t type in RHEL5 i am trying to add new user. I generated new user(myuser_t and myuser_r) using polygen tool and loaded into RHEL5.4; later i added myuser_r:myuser_t in default_type file.
Also mapped a normal user to myuser_u, and relabeled home dirs....
and created a file mysuer_u inside /etc/selinux/targeted/contexts/users
and mapped
system_r:local_login_t:s0 myuser_r:myuser_t:s0
system_r:xdm_t:s0 myuser_r:myuser_t:s0
system_r:updpwd_t:s0 myuser_r:myuser_t:s0
and in /pam.d/login
session required pam_selinux.so open selet_context
But when i logged in permissive mode id -Z gives
myuser_u:myuser_r:updpwd_t
in enforce mode login is not possible.
Am i missing out something? Please give me some idea.
Thanks and regards
shrikanta
Re: trying to add new user in RHEL 5.4
Doing this with RHEL6 will be a lot easier.
Re: trying to add new user in RHEL 5.4