Chapter 2. SELinux Policy Overview

25

This is why, when discussing interaction of processes and files, the type component is what you focus

on.

2.10.1. SELinux Roles

Roles define which SELinux user identities can have access to what domains. Roles are created by the

existence of one or more declarations in a TE rules file in

$SELINUX_SRC/domains/*

:

Simply being in a role is not enough to allow domain transition. If a process is in

role_r

and

domain1_t

, and

role_r

is authorized for

domain2_t

, the process cannot jump to

domain2_t

.

There must be an allow rule for the process transition to take place.

For example, the domains

named_t

and

squid_t

are both in the role

system_r

. However,

named_t

cannot transition to

squid_t

without an allow rule.

This shows the syntax and an allow example for role:

# syntax for role declaration

role

rolename

types

domain(s) ;

4

5

4

5

# example of role declaration from

# $SELINUX_SRC/domains/programs/ldconfig.te

role sysadm_r types ldconfig_t;

/* administrators are allowed access to ldconfig_t domain */

# syntax for role allow

allow

current_role(s)

new_role(s) ;

4

5/4

5

# example of role allow from $SELINUX_SRC/rbac

allow user_r sysadm_r;

Grouping domains into roles is relatively intuitive, since roles are task oriented

3

. Every process has

a role, starting with the system role,

system_r

. Users gain a role at login, which includes using

su

where a new role can come with the new UID, or you can keep your UID and change your

role using

newrole

; however, this is not often done. Domains are changed often and quietly, but

roles rarely change, especially under the targeted policy. Another way to change roles is through a

role_transition

, this is also very rare and currently only used for an administrative role to launch

daemons in a different role under a stricter policy:

role_transition sysadm_r $1_exec_t system_r;

/* When an administrator executes a process with the type of */

/* $1_exec_t, the process transitions from sysadm_r to

*/

/* system_r.

*/

3. Roles can encompass other roles, inheriting the privileges of the included role. This dominance capability is

not used in the targeted policy. This syntax example shows a role that is declared to dominate over, and inherit

the privileges of, sysadm_r and user_r:

dominance {role master_r {role sysadm_r; role user_r;} }