ConstraintStatements

From SELinux Wiki
Revision as of 16:40, 29 November 2009 by RichardHaines (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Constraint Statements

constrain Statement

The constrain statement allows further restriction on permissions for the specified object classes by using boolean expressions covering: source and target types, roles and users as described in the examples.

The statement definition is:

constrain class perm_set expression;


Where:

constrain The constrain keyword.
class One or more object classes. Multiple entries consist of a space separated list enclosed in braces ({}).
perm_set One or more permissions. Multiple entries consist of a space separated list enclosed in braces ({}).
expression The boolean expression of the constraint that is defined as follows:
( expression : expression )
not expression
expression and expression
expression or expression
u1 op u2
r1 role_op r2
t1 op t2
u1 op names
u2 op names
r1 op names
r2 op names
t1 op names
t2 op names
Where:

u1, r1, t1 = Source user, role, type u2, r2, t2 = Target user, role, type

and:

op : == | !=

role_op : == | != | eq | dom | domby | incomp

names : name | { name_list }

name_list : name | name_list name


The statement is valid in:

Monolithic Policy
Base Policy
Module Policy
Yes
Yes
No
Conditional Policy (if) Statement
optional Statement
require Statement
No
No
No


Examples:

These examples have been taken from the Reference Policy source ./policy/constraints file.

# This ''constrain'' statement is the “SELinux process identity 
# change constraint” taken from the Reference Policy source and
# contains multiple expressions.
#
# The overall constraint is on the ''process'' object class with the 
# ''transition'' permission, and is stating that a domain transition 
# is being constrained by the rules listed (u1 == u2 etc.), 
# however only the first two expressions are explained.
#
# The first expression ''u1 == u2'' states that the '''source''' (''u1'') and
# '''target''' (''u2'') user identifiers must be '''equal''' for a ''process'' 
# ''transition'' to be allowed.
#
# However note that there are a number of '''or''' operators that can 
# override this first constraint.
#
# The second expression:
# ''( t1 == can_change_process_identity and t2 == process_user_target )''
# 
# states that if the '''source type''' (''t1'') is '''equal''' to any type
# associated to the ''can_change_process_identity'' attribute, '''and''' 
# the '''target type''' (''t2'') is '''equal''' to any type associated to the
# ''process_user_target'' attribute, then a ''process'' ''transition'' is
# allowed. 

# What this expression means in the 'standard' build Reference 
# Policy is that if the '''source domain''' is either cron_t, 
# firstboot_t, local_login_t, su_login_t, sshd_t or xdm_t (as 
# the ''can_change_process_identity'' attribute has these types 
# associated to it) '''and''' the '''target domain''' is sysadm_t (as that is
# the only type associated to the ''can_change_process_identity'' 
# attribute), then a domain transition is allowed.
#

# SELinux process identity change constraint:

constrain process transition ( 
u1 == u2 
or
( t1 == can_change_process_identity and t2 == process_user_target ) or
( t1 == cron_source_domain and ( t2 == cron_job_domain or u2 == system_u ))
or
( t1 == can_system_change and u2 == system_u )
or 
( t1 == process_uncond_exempt ) );
# This ''constrain'' statement is the “SELinux file related object 
# identity change constraint” taken from the Reference Policy 
# source and contains two expressions.
#
# The overall constraint is on the listed file related object 
# classes (''dir'', ''file'' etc.), covering the ''create'', ''relabelto'', and 
# ''relabelfrom'' permissions. It is stating that when any of the 
# object class listed are being created or relabeled, then they
# are subject to the constraint rules listed (u1 == u2 etc.).
#
# The first expression ''u1 == u2'' states that the '''source''' (''u1'') and
# '''target''' (''u2'') user identifiers (within the security context) 
# must be '''equal''' when creating or relabeling any of the file 
# related objects listed.
#
# The second expression:
# ''or t1 == can_change_object_identity''
# 
# states '''or''' if the '''source type''' (''t1'') is '''equal''' to any type
# associated to the ''can_change_object_identity'' attribute, then
# any of the object class listed can be created or relabeled.
#

# What this expression means in the 'standard' build 
# Reference Policy is that if the '''source domain''' (''t1'') matches a 
# ''type'' entry in the ''can_change_object_identity'' attribute, then
# any of the object class listed can be created or relabeled.
#

# SELinux file related object identity change constraint:

constrain { dir file lnk_file sock_file fifo_file chr_file 
blk_file } { create relabelto relabelfrom } 
(
u1 == u2
or t1 == can_change_object_identity
);


validatetrans Statement

Only file related object classes are currently supported by this statement and it is used to control the ability to change the objects security context.

Note there are no validatetrans statements specified within the Reference Policy source.

The statement definition is:

validatetrans class expression;


Where:

validatetrans The validatetrans keyword.
class One or more file related object classes. Multiple entries consist of a space separated list enclosed in braces ({}).
expression The boolean expression of the constraint that is defined as follows:
( expression : expression ) not expression expression and expression expression or expression u1 op u2 r1 role_op r2 t1 op t2 u1 op names u2 op names r1 op names r2 op names t1 op names t2 op names u3 op names r3 op names t3 op names
colspan="2" Where:

u1, r1, t1 = Old user, role, type

u2, r2, t2 = New user, role, type

u3, r3, t3 = Process user, role, type

and:

op : == | !=

role_op : == | != | eq | dom | domby | incomp

names : name | { name_list }

name_list : name | name_list name


The statement is valid in:

Monolithic Policy
Base Policy
Module Policy
Yes
Yes
No
Conditional Policy (if) Statement
optional Statement
require Statement
No
No
No


Examples:

none yet