MLSStatements

From SELinux Wiki

(Difference between revisions)
Jump to: navigation, search
Revision as of 13:03, 30 November 2009 (edit)
RichardHaines (Talk | contribs)

← Previous diff
Current revision (13:47, 30 November 2009) (edit) (undo)
RichardHaines (Talk | contribs)

 
Line 12: Line 12:
<center>Consisting of a sensitivity and zero or more category entries:</center> <center>Consisting of a sensitivity and zero or more category entries:</center>
-!colspan="2"| 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.+!colspan="2" rowspan="2"| 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.
|- |-
Line 26: Line 26:
|- |-
-| sensitivity [: category, ... +| sensitivity [: category, ... ]
| <center>-</center> | <center>-</center>
-| sensitivity [: category, ... +| sensitivity [: category, ... ]
|- |-
Line 417: Line 417:
|- |-
-|-+|<nowiki>-</nowiki>
|The optional hyphen (-) separator if a high_level is also being defined. |The optional hyphen (-) separator if a high_level is also being defined.
Line 511: Line 511:
|- |-
-!colspan="2"| Where:+!colspan="2" align="left"| Where:
- + u1, r1, t1, l1, h1 = Source user, role, type, low level, high level
-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
- +
-u2, r2, t2, l2, h2 = Target user, role, type, low level, high level+
- +
and: and:
- + op : == | !=
-op : == | !=+ role_mls_op : == | != | eq | dom | domby | incomp
-role_mls_op : == | != | eq | dom | domby | incomp+ names : name | { name_list }
- + name_list : name | name_list name
-names : name | { name_list }+
- +
-name_list : name | name_list name+
|} |}
Line 669: Line 663:
| t3 op names | t3 op names
|- |-
-!colspan="2"| Where:+!colspan="2" align="left"|Where:
- + u1, r1, t1, l1, h1 = Old user, role, type, low level, high level
-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
-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: and:
- + op : == | !=
-op : == | !=+ role_mls_op : == | != | eq | dom | domby | incomp
- + names : name | { name_list }
-role_mls_op : == | != | eq | dom | domby | incomp+ name_list : name | name_list name
- +
-names : name | { name_list }+
- +
-name_list : name | name_list name+
|} |}

Current revision

Contents

[edit] 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.

Security Level (or Level)
Consisting of a sensitivity and zero or more category entries:
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, ... ]
Range
Low
High
sensitivity [: category, ... ]
-
sensitivity [: category, ... ]
For a process or subject this is the current level or sensitivity
For a process or subject this is the Clearance
For an object this is the current level or sensitivity
For an object this is the maximum range
(for SELinux polyinstantiated directories)
SystemLow
SystemHigh
This is the lowest level or classification for the system (for SELinux this is generally 's0', note that there are no categories).
This is the highest level or classification for the system (for SELinux this is generally 's15:c0,c255', although note that they will be the highest set by the policy).
Table 1: Sensitivity and Category = Security Level - this table shows the meanings depending on the context being discussed.


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.


[edit] 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:

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


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;

[edit] 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:

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


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 }

[edit] 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:

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


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;

[edit] 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 stop sign (.) separating two category identifiers means an inclusive set (e.g. c0.c16).
  • The comma (,) separating two category identifiers means a non-contiguous list (e.g. c21,c36,c45).
  • Both separators may be used (e.g. c0.c16, c21,c36,c45).



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:

# 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;

[edit] 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:

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


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;

[edit] 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.


[edit] 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:

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/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 ));

[edit] 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:

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


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 ))));
Personal tools