My view on domains, domain types, roles, domain transitions and more.

A domain is an environment in which a process operates. That environment is defined by the access vectors where a particular process is the sources.

Sometimes people refer to types of processes as domains. This is technically incorrect. Types of processes are domain types.

A domain is a general term for process environments. Processes can have different natures or properties. For example a user process environment can be called a domain and a process of a program can also be called a domain.

In SELinux world we like to "label" everything. So instead of calling a user process environment a domain we call it a user domain. The type of a user process is called a user domain type although technically its a domain type since user processes are processes.

Besides user domains, there are more different domains. These domains are defined by who transitioned to them. For example, init daemons are started by init scripts. The init script process sandbox is called init script domain and process environments that init script domains transition to are called init daemon domains.

Examples of init daemon domains are the environment of the httpd_t init daemon domain type, or postgresql. The main property is that these processes are started by init scripts.

Process environments of programs that user process environments transition to are called application domains, and the type of such a process is called a application domain type.

It depends on what transitions to what, that defines what domain it is. A cgi webapp that operates in its own environment is called a apache daemon domain if the httpd_t init daemon domain transitions to the process environment of a cgi webapp.

There are many more such domains and they are defined by what domain transitioned to them.

Domain transitions occur upon entrypoints. An entrypoint is a defined path to usually a executable file. Types of executable files are called executable file types. They are important in entrypoints to domains.

For example:

apache init script has a executable file type called for example httpd_initrc_exec_t.
When the init_t domain type executes the file with executable file type httpd_initrc_exec_t,
the process of that executable file type will get the initrc_t domain type and the process will operate in the init script domain (init script process environment).

The entrypoint is:
init_t -> httpd_initrc_exec_t

This entrypoint leads to the initrc_t process environment. (init script domain)

Now this starts all over again when the process that has domain type initrc_t runs the apache executable.

Assuming in this example that /usr/sbin/httpd is apaches executable file and that it has a executable file type of httpd_exec_t.

The entrypoint is:
initrc_t -> httpd_exec_t

The init script domain type runs the apache executable file type. There is a rule that says:
when initrc_t executes httpd_exec_t, then transition to the httpd_t process environment type.

initrc_t -> httpd_exec_t -> httpd_t

initrc_t is a (init script) domain type. policy where initrc_t is the source type is called a init script domain.

httpd_exec_t is a executable file type.
initrc_t -> httpd_exec_t is the entrypoint to the httpd_t domain (type)
httpd_t -> is a (init daemon) domain type. policy where httpd_t is the source type is called a init daemon domain.

There are api available that make transitioning to these types of domains easier.

For example you can simply call the init_daemon_domain() interface if your process is started by a init script. proper calling of this single interface will take care of some of the declarations that are required. it will also set up a domain transition pattern.

type myinitdaemondomaintype_t;
type myinitdaemondomaintypeexecutablefiletype_t;
init_daemon_domain(myinitdaemondomaintype_t, myinitdaemondomaintypeexecutablefiletype_t)

This will instruct SELinux to let processes that run in the initrc_t init script domain that execute files with executable file type myinitdaemondomaintypeexecutablefiletype_t, domain transition to the myinitdaemondomaintype_t process enviroment and give that process the init daemon domain type.

initrc_t -> myinitdaemondomaintypeexecutablefiletype_t -> myinitdaemondomaintype_t

This ofcourse requires that file files in question are labelled accordingly.

application domains are handled a bit differently. This is mainly because of RBAC.

Role based access control is a mechanism that allows a single user to operate in various environments (user domains)

This means that you must also define which role is allowed to use the target domain type.

user_t: user domain type
userapp_exec_t: (application) executable file type of the application to transition to.
userapp_t: application domain type

entrypoint:
user_t -> userapp_exec_t

Target of the entry point:
userapp_tRole of the user that this domain transition pattern is defined for:
user_r

type user_t;
type userapp_exec_t;
application_domain(user_t, userapp_exec_t)
role user_r types userapp_t;

domain_transition_pattern(user_t, userapp_exec_t, userapp_t)

Again same idea but its just a bit more complicated than the init daemon domain because users
(and applications started by users) can have different roles.

Applications started by init (system) can only have one role(system_r), So that makes the init daemon domains less complicated.

Explained:
When a user process that operates in the user_t user process environment runs a file with executable file type myapp_exec_t, then the process of that executable file type will run in the myapp_t application process environment (application domain).

Since users can have different roles we also define that particular role to have access to the application domain type.

We also manually define a domain transition pattern (user_t -> myapp_exec_t -> myapp_t)

Keep in mind that domains transitioned to by users also have to deal with roles, unlike domain transitioned to by system processes. processes where the role field in the context is system_r.

Your policy source has many example of the different domains. If you want to write policy for a init daemon than look up an example of a init daemon domain in the source policy, and see if that can get you started. Idem ditto for application domains, apache daemon domains, xinet service domains, dbus service domains and etcetera.

User domains are different. They arent started by other processes. instead a real person logs into the system and by running a tty or pts a new domain is initiated. These transtions are defined both in the user domain policy and selinux mappings, many of which can be defined with the semanage command.

for example:
(real human) -> tty_device_t -> user_t

I wont go into much detail here but i want to touch on the different user domains to consider. Users can have different roles. Roles are mappings to domains. and as explained domain are environments in which processes operate, defined by the policy in which a domain type is a source.

There are two different classes of user domain to consider. user domains that need a login environment, and user domains that do not need a login enviroment. i refer to them as primary and secondary user domains.

An example of a primary login user domain is staff_t. A user can login to a system in the staff_t user domain.

An example of a secundary user domain is webadm_t.

A primary user domain can be allowed to domain transition via roles (RBAC) to this secondary user domain. Thus may not be required to login and have a home directory and etcetera. Secondary user domains are often used for environments that have super user privileges. Like for example the webadm_t environment allows a user process to manage the webserver environment.

Have a look at the different defined user domain in the source policy. look at both staff domain and webadm domain and keep in mind that the first is a primary domain and the latter a secondary domain. By mapping the webadm_r and staff_r roles to a selinux user and mapping this selinux user to a linux login you can make selinux allow users that operate in the staff_t user domain to use Role based access control to domain transition to the secondary webadm_t user domain via sudo or su in conjunction with newrole.