Difference between revisions of "TypeRules"
(New page: = Type Enforcement Rules = The TE rules define what access control privileges are allowed for processes. There are three types of enforcement rule: type_transition, type_change, and type_m...) |
(No difference)
|
Revision as of 14:50, 29 November 2009
Contents
Type Enforcement Rules
The TE rules define what access control privileges are allowed for processes. There are three types of enforcement rule: type_transition, type_change, and type_member that are explained below.
The common format of the Type Enforcement Rule is:
type_rule source_type target_type : class default_type;
Where:
type_rule | The applicable type_transition, type_change, or type_member rule keyword. |
source_type
target_type |
One or more source / target type or attribute identifiers. Multiple entries consist of a space separated list enclosed in braces ({}).
Entries can be excluded from the list by using the negative operator (-). |
class | One or more object classes. Multiple entries consist of a space separated list enclosed in braces ({}). |
default_type | A single type identifier that will become the default process type for a domain transition or the type for object transitions. |
The statements are valid in:
type_transition Statement
The type_transition statement specifies the labeling and object creation allowed between the source_type and target_type when a Domain Transition is requested.
Example - Domain Transition:
# Using the type_transition statement to show a domain transition # (as the statement has the process object class in the # class). # The rule states that when a process of type initrc_t executes # a file of type acct_exec_t, the process type should be changed # to acct_t if allowed by the policy (i.e. Transition from the # initrc_t domain to the acc_t domain). type_transition initrc_t acct_exec_t:process acct_t; # Note that to be able to transition to the acc_t domain the # following minimum permissions need to be granted in the policy # using allow rules (as shown in the allow Rule section). # File needs to be executable in the initrc_t domain: allow initrc_t acct_exec_t:file execute; # The executable file needs an entry point into the acct_t domain: allow acct_t acct_exec_t:file entrypoint; # Process needs permission to transition into the acct_t domain: allow initrc_t acct_t:process transition;
Example - Object Transition:
# Using the type_transition statement to show an object # transition (as it has other than process in the class). # The rule states that when a process of type acct_t creates a # file in the directory of type var_log_t, by default it should # have the type wtmp_t if allowed by the policy. type_transition acct_t var_log_t:file wtmp_t; # Note that to be able to create the new file object with the # wtmp_t type, the following minimum permissions need to be # granted in the policy using allow rules (as shown in the # allow Rule section). # A minimum of: add_name, write and search on the var_log_t # directory. The actual reference policy has: # allow acct_t var_log_t:dir { read getattr lock search ioctl add_name remove_name write }; # A minimum of: create and write on the wtmp_t file. The actual # reference policy has: # allow acct_t wtmp_t:file { create open getattr setattr read write append rename link unlink ioctl lock };
type_change Statement
The type_change statement is used to determine any re-labeling of default types for user space SELinux-aware applications that would then manage any required re-labeling via the libselinux API.
Examples:
# Using the type_change statement to show that when relabeling a # character file with type sysadm_devpts_t on behalf of # auditadm_t, the type auditadm_devpts_t should be used: type_change auditadm_t sysadm_devpts_t:chr_file auditadm_devpts_t;
# Using the type_change statement to show that when relabeling a # character file with any type associated to the attribute # server_ptynode on behalf of staff_t, the type staff_devpts_t # should be used: type_change staff_t server_ptynode:chr_file staff_devpts_t;
type_member Statement
The type_member statement determines whether an object can be polyinstantiated. It is used by SELinux-aware applications that would then manage any required polyinstantiation requirements via the libselinux API (see the Polyinstantiation section). Currently only directories are managed by SELinux-aware applications, although the actual statement is not limited to specific object classes.
Example:
# Using the type_member statement to show that if the source # type is sysadm_t, and the target type is user_home_dir_t, # then use user_home_dir_t as the type on the newly created # directory object. type_member sysadm_t user_home_dir_t:dir user_home_dir_t;