Difference between revisions of "ConstraintStatements"
(New page: = Constraint Statements = == constrain Statement == The constrain statement allows further restriction on permissions for the specified object classes by using boolean expressions covering...) |
|||
Line 61: | Line 61: | ||
| | | | ||
| t2 op names | | t2 op names | ||
− | | | + | |- |
− | + | ||
|'''Where:''' | |'''Where:''' | ||
Line 77: | Line 76: | ||
<nowiki>name_list : name | name_list name</nowiki> | <nowiki>name_list : name | name_list name</nowiki> | ||
− | + | |- | |
|} | |} | ||
Line 109: | Line 108: | ||
These examples have been taken from the Reference Policy source ./policy/constraints file. | These examples have been taken from the Reference Policy source ./policy/constraints file. | ||
<pre> | <pre> | ||
− | <nowiki># This </nowiki> | + | <nowiki># This </nowiki>constrain statement is the SELinux process identity |
− | <nowiki># change | + | <nowiki># change constraint taken from the Reference Policy source and</nowiki> |
<nowiki># contains multiple expressions.</nowiki> | <nowiki># contains multiple expressions.</nowiki> | ||
<nowiki>#</nowiki> | <nowiki>#</nowiki> | ||
− | <nowiki># The overall constraint is on the </nowiki> | + | <nowiki># The overall constraint is on the </nowiki>process object class with the |
− | <nowiki># </nowiki> | + | <nowiki># </nowiki>transition permission, and is stating that a domain transition |
<nowiki># is being constrained by the rules listed (u1 == u2 etc.), </nowiki> | <nowiki># is being constrained by the rules listed (u1 == u2 etc.), </nowiki> | ||
<nowiki># however only the first two expressions are explained.</nowiki> | <nowiki># however only the first two expressions are explained.</nowiki> | ||
<nowiki>#</nowiki> | <nowiki>#</nowiki> | ||
− | <nowiki># The first expression </nowiki> | + | <nowiki># The first expression </nowiki>u1 == u2 states that the source (u1) and |
− | <nowiki># </nowiki> | + | <nowiki># </nowiki>target (u2) user identifiers must be equal for a process |
− | <nowiki># </nowiki> | + | <nowiki># </nowiki>transition to be allowed. |
<nowiki>#</nowiki> | <nowiki>#</nowiki> | ||
− | <nowiki># However note that there are a number of </nowiki> | + | <nowiki># However note that there are a number of </nowiki>or operators that can |
<nowiki># override this first constraint.</nowiki> | <nowiki># override this first constraint.</nowiki> | ||
<nowiki>#</nowiki> | <nowiki>#</nowiki> | ||
<nowiki># The second expression:</nowiki> | <nowiki># The second expression:</nowiki> | ||
− | <nowiki># </nowiki> | + | <nowiki># </nowiki>( t1 == can_change_process_identity and t2 == process_user_target ) |
<nowiki># </nowiki> | <nowiki># </nowiki> | ||
− | <nowiki># states that if the </nowiki> | + | <nowiki># states that if the </nowiki>source type (t1) is equal to any type |
− | <nowiki># associated to the </nowiki> | + | <nowiki># associated to the </nowiki>can_change_process_identity attribute, and |
− | <nowiki># the </nowiki> | + | <nowiki># the </nowiki>target type (t2) is equal to any type associated to the |
− | <nowiki># </nowiki> | + | <nowiki># </nowiki>process_user_target attribute, then a process transition is |
<nowiki># allowed. </nowiki> | <nowiki># allowed. </nowiki> | ||
<nowiki># What this expression means in the 'standard' build Reference </nowiki> | <nowiki># What this expression means in the 'standard' build Reference </nowiki> | ||
− | <nowiki># Policy is that if the </nowiki> | + | <nowiki># Policy is that if the </nowiki>source domain is either cron_t, |
<nowiki># firstboot_t, local_login_t, su_login_t, sshd_t or xdm_t (as </nowiki> | <nowiki># firstboot_t, local_login_t, su_login_t, sshd_t or xdm_t (as </nowiki> | ||
− | <nowiki># the </nowiki> | + | <nowiki># the </nowiki>can_change_process_identity attribute has these types |
− | <nowiki># associated to it) </nowiki> | + | <nowiki># associated to it) </nowiki>and the target domain is sysadm_t (as that is |
− | <nowiki># the only type associated to the </nowiki> | + | <nowiki># the only type associated to the </nowiki>can_change_process_identity |
<nowiki># attribute), then a domain transition is allowed.</nowiki> | <nowiki># attribute), then a domain transition is allowed.</nowiki> | ||
<nowiki>#</nowiki> | <nowiki>#</nowiki> | ||
Line 157: | Line 156: | ||
<pre> | <pre> | ||
− | <nowiki># This </nowiki> | + | <nowiki># This </nowiki>constrain statement is the SELinux file related object |
− | <nowiki># identity change | + | <nowiki># identity change constraint taken from the Reference Policy </nowiki> |
<nowiki># source and contains two expressions.</nowiki> | <nowiki># source and contains two expressions.</nowiki> | ||
<nowiki>#</nowiki> | <nowiki>#</nowiki> | ||
<nowiki># The overall constraint is on the listed file related object </nowiki> | <nowiki># The overall constraint is on the listed file related object </nowiki> | ||
− | <nowiki># classes (</nowiki> | + | <nowiki># classes (</nowiki>dir, file etc.), covering the create, relabelto, and |
− | <nowiki># </nowiki> | + | <nowiki># </nowiki>relabelfrom permissions. It is stating that when any of the |
<nowiki># object class listed are being created or relabeled, then they</nowiki> | <nowiki># object class listed are being created or relabeled, then they</nowiki> | ||
<nowiki># are subject to the constraint rules listed (u1 == u2 etc.).</nowiki> | <nowiki># are subject to the constraint rules listed (u1 == u2 etc.).</nowiki> | ||
<nowiki>#</nowiki> | <nowiki>#</nowiki> | ||
− | <nowiki># The first expression </nowiki> | + | <nowiki># The first expression </nowiki>u1 == u2 states that the source (u1) and |
− | <nowiki># </nowiki> | + | <nowiki># </nowiki>target (u2) user identifiers (within the security context) |
− | <nowiki># must be </nowiki> | + | <nowiki># must be </nowiki>equal when creating or relabeling any of the file |
<nowiki># related objects listed.</nowiki> | <nowiki># related objects listed.</nowiki> | ||
<nowiki>#</nowiki> | <nowiki>#</nowiki> | ||
<nowiki># The second expression:</nowiki> | <nowiki># The second expression:</nowiki> | ||
− | <nowiki># </nowiki> | + | <nowiki># </nowiki>or t1 == can_change_object_identity |
<nowiki># </nowiki> | <nowiki># </nowiki> | ||
− | <nowiki># states </nowiki> | + | <nowiki># states </nowiki>or if the source type (t1) is equal to any type |
− | <nowiki># associated to the </nowiki> | + | <nowiki># associated to the </nowiki>can_change_object_identity attribute, then |
<nowiki># any of the object class listed can be created or relabeled.</nowiki> | <nowiki># any of the object class listed can be created or relabeled.</nowiki> | ||
<nowiki>#</nowiki> | <nowiki>#</nowiki> | ||
<nowiki># What this expression means in the 'standard' build </nowiki> | <nowiki># What this expression means in the 'standard' build </nowiki> | ||
− | <nowiki># Reference Policy is that if the </nowiki> | + | <nowiki># Reference Policy is that if the </nowiki>source domain (t1) matches a |
− | <nowiki># </nowiki> | + | <nowiki># </nowiki>type entry in the can_change_object_identity attribute, then |
<nowiki># any of the object class listed can be created or relabeled.</nowiki> | <nowiki># any of the object class listed can be created or relabeled.</nowiki> | ||
<nowiki>#</nowiki> | <nowiki>#</nowiki> | ||
Line 224: | Line 223: | ||
| | | | ||
|( expression : expression ) | |( expression : expression ) | ||
− | + | |- | |
+ | | | ||
| not expression | | not expression | ||
− | + | |- | |
+ | | | ||
| expression and expression | | expression and expression | ||
− | + | |- | |
+ | | | ||
| expression or expression | | expression or expression | ||
− | + | |- | |
+ | | | ||
| u1 op u2 | | u1 op u2 | ||
− | + | |- | |
+ | | | ||
| r1 role_op r2 | | r1 role_op r2 | ||
− | + | |- | |
+ | | | ||
| t1 op t2 | | t1 op t2 | ||
− | + | |- | |
+ | | | ||
| u1 op names | | u1 op names | ||
− | + | |- | |
+ | | | ||
| u2 op names | | u2 op names | ||
− | + | |- | |
+ | | | ||
| r1 op names | | r1 op names | ||
− | + | |- | |
+ | | | ||
| r2 op names | | r2 op names | ||
− | + | |- | |
+ | | | ||
| t1 op names | | t1 op names | ||
− | + | |- | |
+ | | | ||
| t2 op names | | t2 op names | ||
− | + | |- | |
+ | | | ||
| u3 op names | | u3 op names | ||
− | + | |- | |
+ | | | ||
| r3 op names | | r3 op names | ||
− | + | |- | |
+ | | | ||
| t3 op names | | t3 op names | ||
− | |||
|- | |- | ||
− | | | + | |'''Where:''' |
u1, r1, t1 = Old user, role, type | u1, r1, t1 = Old user, role, type | ||
Line 266: | Line 279: | ||
'''and:''' | '''and:''' | ||
− | op : == | != | + | <nowiki>op : == | !=</nowiki> |
− | role_op : == | != | eq | dom | domby | incomp | + | <nowiki>role_op : == | != | eq | dom | domby | incomp</nowiki> |
− | names : name | { name_list } | + | <nowiki>names : name | { name_list }</nowiki> |
− | + | ||
− | + | ||
+ | <nowiki>name_list : name | name_list name</nowiki> | ||
+ | |- | ||
|} | |} | ||
Revision as of 17:28, 29 November 2009
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:
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 | |
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:
Examples:
none yet