Chapter 3. Targeted Policy Overview

43

3.5. Understanding the Roles and Users in the Targeted Policy

Building on your understanding from reading Section 2.10 SELinux Users and Roles, this section

covers the specific roles enabled for the targeted policy. As explained previously, roles are not very

active in the targeted policy, but can be an essential part of a localized SELinux installation. You can

see that

unconfined_t

is in every role, which significantly reduces the usefulness of roles in the

targeted policy. Using roles more extensively requires a change to the strict policy paradigm, where

every process runs in an individually considered domain.

Effectively, there are only two roles in the targeted policy:

system_r

and

object_r

. The initial role

is

system_r

, and everything else inherits that role. The remaining roles are defined for compatibility

purposes between the targeted policy and strict policy.

1

Of the four roles, three are defined by the policy. The role

object_r

is an implied role and is not found

in policy source. Since roles are created and populated by types through one or more declarations in

$SELINUX_SRC/domains/*

, there is not a single file that declares all the roles. To generate the lists

of types and their roles in this section, the policy analysis tool apol was used. Usage of this tool is

explained in Section 6.3 Using apol for Policy Analysis.

system_r

This role is for all system processes except user processes:

unconfined_t

httpd_t

httpd_sys_script_t

httpd_suexec_t

httpd_php_t

httpd_helper_t

dhcpd_t

ldconfig_t

mailman_queue_t

mailman_mail_t

mailman_cgi_t

system_mail_t

mysqld_t

named_t

ndc_t

nscd_t

ntpd_t

portmap_t

postgresql_t

snmpd_t

squid_t

syslogd_t

winbind_t

ypbind_t

user_r

This is the default user role for regular Linux users. In a strict policy, individual users might

be used, allowing for the users to have special roles to do privileged operations. In the targeted

policy, all users run in a single domain:

unconfined_t

1. Any of the roles could have been chosen for the targeted policy, but system_r already had existing autho 

rization for the daemon domains, simplifying the process. This was done in this fashion because there is no role

aliasing mechanism.