Difference between revisions of "NB MLS"
(→Managing Security Levels via Dominance Rules)
|Line 158:||Line 158:|
Revision as of 20:47, 13 September 2010
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:
- Processes and objects can be given a range that represents the low and high security levels.
- The security level can be more complex, in that it is a hierarchical sensitivity and zero or more non-hierarchical categories.
- Allowing a process access to an object is managed by "dominance" rules applied to the security levels.
- 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).
- 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.
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.
|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.|
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|
|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.|
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:
- 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.
- 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.
- 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).
- 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:
- 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.
- 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.