SELinux Type Enforcement.
Everything on your system is a object. There are domain objects aka subjects and there are file objects aka objects,
Domain objects are processes. A process can be user process or a application process. An example of a user process is user_t and another example of a user process is system_t. system_t is system user in traditional terms root. A application process that is started by the system is called a init_daemon_domain and a application process started by a user is called a application_domain.

file objects can be many things. For example, files, dirs but also sock_files or block_files and even ports, interfaces and nodes can be considered file objects.Arguably the most important file object is called the application_executable_file. If a process executes that file object, than the process that started can either run the application in the current user process, or can transition to a application process. This decision is defined in policy. The process that executes a application_executable_file will by default not transtition.

Example default:

system_t(system user process) runs app_exec_t(application executable file) and does not transition, The application process runs in system_t (system user process) 

user_t (user process) runs app_exec_t (application_executable_file) and does not transition. The application process runs in user_t(user process)

Transition Example (requires domain_auto_trans):

system_t(system user process) runs app_exec_t(application_executable_file) and transitions. The application process runs in app_t (init_daemon_domain)

user_t(user process) runs app_exec_t(application_executable_file) and transitions. The application process runs in app_t (application_domain)

Domain objects, file objects, user domain, application domain, init daemon domain, application executable file

Domain objects generally interact with file objects but can also interact with its own process and other processes. In a AVC denail, a domain object is always refered to as a scontext or source context. However, a tcontext or target context can be both a domain object and file object,

In order to differentiate between the many objects, selinux in the kernel provides classes. A typical class for a domain object is process. A typical class for a file object is a file.

Attributes specify the attributes of any class. A typical attribute for a domain object, process is signal. A typical attribute for a file object, file is read.

By default any interaction between objects is denied. A typical private policy rule to allow interaction between objects is:

allow domain_object_t file_object)t:file read;
Allows the domain_object with type domain_object_t, the attribute read, to the class file of any file object with type file_object_t.

allow domain_object_t user_t:process signal;
allows the domain object with type domain_object_t, the attribute signal, to the class process of any domain object with type user_t.

scontext, tcontext, classes , attributes

Policy modules usually have 3 files. A .te (type enforcement) file which houses private declarations and private policy. A .if (interface) file which holds public declarations of and public policy. A .fc (file context) file which specifies the security contexts of object files.

A typical minimal .te file has a policy_module private declaration which defines the name and version of the policy module. It also has the private type declaration of the file that gets executed. for example app_exec_t. After we declared a name for this object type we can now define the purpose of this object type. which is, as the name of the object type suggest a application executable file.

domain object types are sometimes declared private and sometimes declared public, the domain object type and its purpose init_daemon_domain is always declared in private since it is usually executed by the same system user aka system_t (init). However domain object types that are application domains are executed by user domains, which can be many and can come and go, as one can create infinite unique user process. The interface file, and in particular the per_role_template in the interface file helps one declared these processes in public so that any user domain can call this template and use these public declarations and public policy.

The security server makes a distinction between domain objects by means of the role_r in the security context, One should, either in private or in public declare which roles are compatible with the declared domain type.

Example of a very minimal type enforcment file for a init_daemon_domain:

policy_module(app,1.0.0)

type app_exec_t;
application_executable_file(app_exec_t)

type app_t;
init_daemon_domain(app_t,app_exec_t)
role sysem_r types app_t;

allow app_t app_t:process sigchld;

allow app_t file_object_t:file read;

One would have to define the security context for the file object app_exec_t that gets executed in the file context file:

/usr/bin/app	--      gen_context(system_u:object_r:app_exec_t,s0)

Note that security contexts of file objects have a generic role of object_r. the role_r is only used with domain objects, as objects never interact with subjects. file objects are never source contexts.