NB MLS

From SELinux Wiki

(Difference between revisions)
Jump to: navigation, search
Revision as of 14:23, 16 May 2010 (edit)
RichardHaines (Talk | contribs)
(New page: = Multi-Level Security and Multi-Category Security = As stated in the Mandatory Access Control (MAC) section as well as supporting Type Enforcement (TE), SELinux also support...)
← Previous diff
Revision as of 14:24, 16 May 2010 (edit) (undo)
RichardHaines (Talk | contribs)
(Multi-Level Security and Multi-Category Security)
Next diff →
Line 1: Line 1:
- 
= Multi-Level Security and Multi-Category Security = = Multi-Level Security and Multi-Category Security =
As stated in the [[NB_MAC | Mandatory Access Control (MAC)]] section as well as supporting Type Enforcement (TE), SELinux also supports MLS and MCS by adding an optional <tt>level</tt> or <tt>range</tt> entry to the security context. This section gives a brief introduction to MLS and MCS. As stated in the [[NB_MAC | Mandatory Access Control (MAC)]] section as well as supporting Type Enforcement (TE), SELinux also supports MLS and MCS by adding an optional <tt>level</tt> or <tt>range</tt> entry to the security context. This section gives a brief introduction to MLS and MCS.
Line 7: Line 6:
This ensures confidentiality as the process can copy a file up to the secret level, but can never re-read that content unless the process "steps up to that level", also the process cannot write files to the lower levels as confidential information would then drift downwards. This ensures confidentiality as the process can copy a file up to the secret level, but can never re-read that content unless the process "steps up to that level", also the process cannot write files to the lower levels as confidential information would then drift downwards.
-To achieve this level of control, the MLS extensions to SELinux make use of constraints similar to those described in the type enforcement [[NB_TE#Constraints | Constraints]] section, except that the statement is called [[MLSSStatements | mlsconstrain]]. +To achieve this level of control, the MLS extensions to SELinux make use of constraints similar to those described in the type enforcement [[NB_TE#Constraints | Constraints]] section, except that the statement is called [[MLSStatements | mlsconstrain]].
However, as always life is not so simple as: However, as always life is not so simple as:

Revision as of 14:24, 16 May 2010

Contents

Multi-Level Security and Multi-Category Security

As stated in the Mandatory Access Control (MAC) section as well as supporting Type Enforcement (TE), SELinux also supports MLS and MCS by adding an optional level or range entry to the security context. This section gives a brief introduction to MLS and MCS.

The Security Levels and Data Flows diagram shows a simple view where security levels represent the classification of files within a file server. The security levels are strictly hierarchical and conform to the Bell-La Padula model (BLP) in that (in the case of SELinux) a process (running at the "Confidential" level) can read / write at their current level but only read down levels or write up levels (the assumption here is that the process is authorised).

This ensures confidentiality as the process can copy a file up to the secret level, but can never re-read that content unless the process "steps up to that level", also the process cannot write files to the lower levels as confidential information would then drift downwards.

To achieve this level of control, the MLS extensions to SELinux make use of constraints similar to those described in the type enforcement Constraints section, except that the statement is called mlsconstrain.

However, as always life is not so simple as:

  1. Processes and objects can be given a range that represents the low and high security levels.
  2. The security level can be more complex, in that it is a hierarchical sensitivity and zero or more non-hierarchical categories.
  3. Allowing a process access to an object is managed by "dominance" rules applied to the security levels.
  4. Trusted processes can be given privileges that will allow them to bypass the BLP rules and basically do anything (that the security policy allowed of course).
  5. Some objects do not support separate read / write functions as they need to read / respond in cases such as networks.

The sections that follow discuss the format of a security level and range, and how these are managed by the constraints mechanism within SELinux using the "dominance" rules.

Security Levels

Table 1 shows the components that make up a security level and how two security levels form a range for the fourth and optional [:level] of the security context within an MLS / MCS environment.

The table also adds terminology in general use as other terms can be used that have the same meanings.


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 (see the MLS Language Statements section), however when discussing these the following terms can also be used: labels, classifications, and compartments.
sensitivity [: category, ... ]
also known as:
Sensitivity Label
Consisting of a classification and compartment.
<- 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: Level, Label, Category or Compartment - this table shows the meanings depending on the context being discussed.

The format used in the policy language statements is fully described in the MLS Statements section, however a brief overview follows.

MLS / MCS Range Format

The following components are used to define the MLS / MCS security levels within the security context:

user:role:type:sensitivity[:category,...]  -  sensitivity [:category,...]
---------------x------------------------x-----x-------------------------x
               |         level          |  -  |        level            |
               |                                                        |
                                        |range|

Where:

sensitivity Sensitivity levels are hierarchical with (traditionally) s0 being the lowest. These values are defined using the sensitivity language statement. To define their hierarchy, the dominance statement is used.

For MLS systems the highest sensitivity is the last one defined in the dominance statement (low to high). Traditionally the maximum for MLS systems is s15 (although the maximum value for the Reference Policy is a compile time option).

For MCS systems there is only one sensitivity defined, and that is s0.

category Categories are optional (i.e. there can be zero or more categories) and they form unordered and unrelated lists of "compartments". These values are defined using the category statement, where for example c0.c3 represents a range (c0 c1 c3) and c0, c3, c7 represent an unordered list. Traditionally the values are between c0 and c255 (although the maximum value for the Reference Policy is a compile time option).
level The level is a combination of the sensitivity and category values that form the actual security level. These values are defined using the level statement.


Translating Levels

When writing policy for MLS / MCS security level components it is usual to use an abbreviated form such as s0, s1 etc. to represent sensitivities and c0, c1 etc. to represent categories. This is done simply to conserve space as they are held on files as extended attributes and also in memory. So that these labels can be represented in human readable form a translation service is provided via the setrans.conf configuration file that uses the mcstransd daemon. For example s0 = Unclassified, s15 = TopSecret and c0 = Finance, c100 = SpyStories (unfortunately the translation does not support spaces in words). The semanage(8) command can be used to set up this translation and is shown in the Global Configuration Files section.

Managing Security Levels via Dominance Rules

As stated earlier, allowing a process access to an object is managed by "dominance" rules applied to the security levels. These rules are as follows:

  1. Security Level 1 dominates Security Level 2 - If the sensitivity of Security Level 1 is equal to or higher than the sensitivity of Security Level 2 and the categories of Security Level 1 are the same or a superset of the categories of Security Level 2.
  1. Security Level 1 is dominated by Security Level 2 - If the sensitivity of Security Level 1 is equal to or lower than the sensitivity of Security Level 2 and the categories of Security Level 1 are a subset of the categories of Security Level 2.
  1. Security Level 1 equals Security Level 2 - If the sensitivity of Security Level 1 is equal to Security Level 2 and the categories of Security Level 1 and Security Level 2 are the same set (sometimes expressed as: both Security Levels dominate each other).
  1. Security Level 1 is incomparable to Security Level 2 - If the categories of Security Level 1 and Security Level 2 cannot be compared (i.e. neither Security Level dominates the other).

To illustrate the usage of these rules, the MLS Security Levels example table lists the security level attributes in a table to show example files (or documents) that have been allocated labels such as s3:c0. The process that accesses these files (e.g. an editor) is running with a range of s0 - s3:c1.c5 and has access to the files highlighted within the grey box area.

As the MLS dominance Statement is used to enforce the sensitivity hierarchy, the security levels now follow that sequence (lowest = s0 to highest = s3) with the categories being unordered lists of "compartments". To allow the process access to files within its scope and within the dominance rules, the process will be constrained by using the mlsconstrain statement as illustrated in the MLS constrain diagram.

So using the MLS constrain diagram:

  1. To allow write-up, the source level (l1) must be dominated by the target level (l2):
    Source level = s0:c3 or s1:c1
    Target level = s2:c1.c4

As can be seen, either of the source levels are dominated by the target level.

  1. To allow read-down, the source level (l1) must dominate the target level (l2):
    Source level = s2:c1.c4
    Target level = s0:c3

As can be seen, the source level does dominate the target level.

However in the real world the SELinux MLS Reference Policy does not allow the write-up unless the process has a special privilege (by having the domain type added to an attribute), although it does allow the read-down. The default is to use l1 eq l2 (i.e. the levels are equal). The reference policy MLS source file (policy/mls) shows these mlsconstrain statements.

MLS Labeled Network and Database Support

Networking for MLS is supported via the NetLabel CIPSO (commercial IP security option) service as discussed in the SELinux Networking Support section.

PostgreSQL supports labeling for MLS database services as discussed in the "Security-Enhanced PostgreSQL Security Wiki".

Common Criteria Certification

While the Common Criteria certification process is beyond the scope of this Notebook, it is worth highlighting that specific Red Hat GNU / Linux versions of software, running on specific hardware platforms with SELinux / MLS policy enabled, have passed the Common Criteria evaluation process. Note, for the evaluation (and deployment) the software and hardware are tied together, therefore whenever an update is carried out, an updated certificate should be obtained.

The Red Hat evaluation process cover the:

  • Labeled Security Protection Profile (LSPP ) - This describes how systems that implement security labels (i.e. MLS) should function.
  • Controlled Access Protection Profile (CAPP) - This describes how systems that implement DAC should function.

An interesting point:

  • Both Red Hat Linux 5.1 and Microsoft Server 2003 (with XP) have both been certified to EAL4+ , however while the evaluation levels may be the same the Protection Profiles that they were evaluated under were: Microsoft CAPP only, Red Hat CAPP and LSPP. Therefore always look at the protection profiles as they define what was actually evaluated.



    Personal tools