MLSStatements
Contents
MLS Statements
The optional MLS policy extension adds an additional security context component that consists of the following highlighted entries:
user:role:type:sensitivity[:category,...]- sensitivity [:category,...]
These consist of a mandatory hierarchical sensitivity and optional non-hierarchical category's. The combination of the two comprise a level or security level as shown in Table 1. Depending on the circumstances, there can be one level defined or a range as shown in Table 1.
Note that SELinux uses level, sensitivity and category in the language statements, however when discussing these the following terms can also be used: labels, classifications, and compartments. | ||
---|---|---|
sensitivity [: category, ... ] | ||
sensitivity [: category, ... ] | |
sensitivity [: category, ... ] |
To make the security levels more meaningful, it is possible to use the setransd daemon to translate these to human readable formats. The semanage command will allow this mapping to be defined as discussed in the ./setrans.conf file section.
sensitivity Statement
The sensitivity statement defines the MLS policy sensitivity identifies and optional alias identifiers.
The statement definition is:
sensitivity identifier;
Or
sensitivity sens_id alias alias_id [ alias_id ];
Where:
sensitivity | The sensitivity keyword. |
sens_id | The sensitivity identifier. |
alias | The optional alias keyword. |
alias_id | One or more alias identifiers in a space separated list. |
The statement is valid in:
Examples:
# The MLS Reference Policy default is to assign 16 ''sensitivity'' # identifiers (s0 to s15): sensitivity s0; .... sensitivity s15; # The policy does not specify any ''alias'' entries, however a valid # example would be: sensitivity s0 alias secret wellmaybe ornot;
MLS dominance Statement
When more than one sensitivity Statement is defined within a policy, then a dominance statement is required to define the actual hierarchy between all sensitivities.
The statement definition is:
dominance { sens_id ... }
Where:
dominance | The dominance keyword. |
sens_id | A space separated list of previously declared sensitivity identifiers (or alias) in the order lowest to highest. They are enclosed in braces ({}), and note that there is no terminating semi-colon (;). |
The statement is valid in:
Example:
# The MLS Reference Policy ''dominance'' statement defines ''s0'' as the # lowest and ''s15'' as the highest sensitivity level: dominance { s0 s1 s2 s3 s4 s5 s6 s7 s8 s9 s10 s11 s12 s13 s14 s15 }
category Statement
The category statement defines the MLS policy category identifiers[1] and optional alias identifiers.
The statement definition is:
category cat_id;
Or
category cat_id alias alias_id;
Where:
category | The category keyword. |
cat_id | The category identifier. |
alias | The optional alias keyword. |
alias_id | One or more alias identifiers in a space separated list. |
The statement is valid in:
Examples:
# The MLS Reference Policy default is to assign 256 ''category'' # identifiers (c0 to c255): category c0; ... category c255; # The policy does not specify any ''alias'' entries, however a valid # example would be: category c0 alias planning development benefits;
level Statement
The level statement enables the previously declared sensitivity and category identifiers to be combined into a Security Level.
Note there must only be one level statement for each sensitivity Statement.
The statement definition is:
level sens_id [ :category_id ];
Where:
level | The level keyword. |
sens_id | A previously declared sensitivity identifier. |
category_id | An optional set of zero or more previously declared category identifiers that are preceded by a colon (:), that can be written as follows:
|
The statement is valid in:
Examples:
# The MLS Reference Policy default is to assign each Security # Level with the complete set of categories (i.e. the inclusive # set from c0 to c255): level s0:c0.c255; ... level s15:c0.c255;
range_transition Statement
The range_transition statement is primarily used by the init process or administration commands to ensure processes run with their correct MLS range (for example init would run at SystemHigh and needs to initialise / run other processes at their correct MLS range). The statement was enhanced in Policy version 21 to accept other object classes.
The statement definition is (for pre-policy version 21):
range_transition source_domain target_exectype new_mls_range;
or (for policy version 21 and greater):
range_transition source_domain target_exectype : class new_mls_range;
Where:
range_transition | The range_transition keyword. |
source_domain | A source process domain (as only the process object class is supported). |
target_exectype | A target executable type or attribute. (i.e. an identifier for a file that has the execute permission set. |
class | The optional object class keyword (this allows policy versions 21 and greater to specify a class other than the default of process). |
new_mls_range | The new MLS range for the object class. The format of this field is described in the MLS range Definition section. |
The statement is valid in:
Examples:
# A range_transition statement from the MLS Reference Policy # showing that a process anaconda_t can transition between # systemLow and systemHigh depending on calling applications # level. range_transition anaconda_t init_script_file_type:process s0 - s15:c0.c255; # Two range_transition statements from the MLS Reference Policy # showing that init will transition the audit and cups daemon # to systemHigh (that is the lowest level they can run at). range_transition initrc_t auditd_exec_t:process s15:c0.c255; range_transition initrc_t cupsd_exec_t:process s15:c0.c255;
MLS range Definition
The MLS range is appended to a number of statements and defines the lowest and highest security levels. The range can also consist of a single level as discussed at the start of the MLS section.
The definition is:
low_level
Or
low_level - high_level
Where:
low_level | The processes lowest level identifier that has been previously declared by a level Statement.
If a high_level is not defined, then it is taken as the same as the low_level. |
- | The optional hyphen (-) separator if a high_level is also being defined. |
high_level | The processes highest level identifier that has been previously declared by a level Statement. |
mlsconstrain Statement
The mlsconstrain statement allows further restriction on permissions for the specified object classes by using boolean expressions covering: source and target types, roles, users and security levels as described in the examples.
The statement definition is:
mlsconstrain class perm_set expression;
Where:
mlsconstrain | The mlsconstrain 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_mls_op r2 | |
t1 op t2 | |
l1 role_mls_op l2 | |
l1 role_mls_op h2 | |
h1 role_mls_op l2 | |
h1 role_mls_op h2 | |
l1 role_mls_op h1 | |
l2 role_mls_op h2 | |
u1 op names | |
u2 op names | |
r1 op names | |
r2 op names | |
t1 op names | |
t2 op names | |
Where:
u1, r1, t1, l1, h1 = Source user, role, type, low level, high level u2, r2, t2, l2, h2 = Target user, role, type, low level, high level and: op : == | != role_mls_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/mls constraints file (the mcs file supports the MCS constraints).
These are built into the policy at build time and add constraints to many of the object classes.
# The MLS Reference Policy mlsconstrain statement for searching # directories that comprises of multiple expressions. Only the # first two expressions are explained. # # Expression 1 ( l1 dom l2 ) reads as follows: # The dir object class search permission is allowed if the # source lowest security level is dominated by the targets # lowest security level. # OR # Expression 2 (( t1 == mlsfilereadtoclr ) and ( h1 dom l2 )) # reads as follows: # If the source type is equal to a type associated to the # mlsfilereadtoclr attribute and the source highest security # level is dominated by the targets lowest security level, # then search permission is allowed on the dir object class. mlsconstrain dir search (( l1 dom l2 ) or (( t1 == mlsfilereadtoclr ) and ( h1 dom l2 )) or ( t1 == mlsfileread ) or ( t2 == mlstrustedobject ));
mlsvalidatetrans Statement
The mlsvalidatetrans is the MLS equivalent of the validatetrans statement and is only used for file related object classes where it is used to control the ability to change the objects security context.
The statement definition is:
mlsvalidatetrans class expression;
Where:
mlsvalidatetrans | The mlsvalidatetrans keyword. |
class | One or more file type 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_mls_op r2 | |
t1 op t2 | |
l1 role_mls_op l2 | |
l1 role_mls_op h2 | |
h1 role_mls_op l2 | |
h1 role_mls_op h2 | |
l1 role_mls_op h1 | |
l2 role_mls_op h2 | |
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, l1, h1 = Old user, role, type, low level, high level u2, r2, t2, l2, h2 = New user, role, type, low level, high level u3, r3, t3, l3, h3 = Process user, role, type, low level, high level and: op : == | != role_mls_op : == | != | eq | dom | domby | incomp names : name | { name_list } name_list : name | name_list name |
---|
The statement is valid in:
Examples:
This example has been taken from the Reference Policy source ./policy/mls file.
# The MLS Reference Policy mlsvalidatetrans statement for # managing the file upgrade/downgrade rules that comprises of # multiple expressions. Only the first two expressions are # explained. # # Expression 1: ( l1 eq l2 ) reads as follows: # For a file related object to change security context, its # current (old) low security level must be equal to the new # objects low security level. # # The second part of the expression: # or (( t3 == mlsfileupgrade ) and ( l1 domby l2 )) reads as # follows: # or the process type must equal a type associated to the # mlsfileupgrade attribute and its current (old) low security # level must be dominated by the new objects low security level. # mlsvalidatetrans { dir file lnk_file chr_file blk_file sock_file fifo_file } ((( l1 eq l2 ) or (( t3 == mlsfileupgrade ) and ( l1 domby l2 )) or (( t3 == mlsfiledowngrade ) and ( l1 dom l2 )) or (( t3 == mlsfiledowngrade ) and ( l1 incomp l2 ))) and (( h1 eq h2 ) or (( t3 == mlsfileupgrade ) and ( h1 domby h2 )) or (( t3 == mlsfiledowngrade ) and ( h1 dom h2 )) or (( t3 == mlsfiledowngrade ) and ( h1 incomp h2 ))));
Cite error: <ref>
tags exist, but no <references/>
tag was found