MULTILEVEL SECURITY


Overview

 

The Multilevel Security (MLS) model is the result of an effort to create secure computer systems for the US military.   It models the scheme that is used to control information access within the US military.  In the military scheme, and in the MLS model, each user has a clearance CU drawn from a setC.  An example isC  = {Top Secret, Confidential, Unclassified}. These clearances are ordered, so Top Secret > Confidential > Unclassified.  Information, represented as an object O, has a classification CO that is also drawn from C.  A person may never see information above his or her clearance.  For example, a user with clearance Confidential may never see information with a classification of Top Secret; he or she may only see information classified at her clearance (Confidential) or below (Unclassified for the set C  above).

 

The name “Multilevel” refers to a class of computer system in which not all users of the system are cleared for all the data on the system. This is contrasted with a dedicated system in which all users have access to all data on the system.  A dedicated system may not require special controls to enforce the policy described above.  For example, one could keep only data at the Confidential level and only allow users cleared at the Confidential level to have access to the system.  In a multilevel system, operations take place at multiple levels, so that users may require access to Top Secret data using the same system in which Unclassified users are accessing Unclassified data.  In this case, controls are necessary to ensure each user can only access data for which he or she is cleared.

 

Clearances and classifications alone are too coarse grained to apply the principle of least privilege, which requires that a subject only be given that access which is necessary for it to complete it’s task.  A user who is working on the design of a quiet submarine propulsor does not need to know the identity of CIA operatives, regardless of the classification of the relevant information.

 

A finer granularity is achieved through the use of categories.  Objects and users have a security level[1].  This level is composed of a clearance (for subjects) or classification (for objects) together with a set of categories. Each category represents a collection of related information.  For example, information on the SSN-XX propulsor might be in the SSNXX-propulsor category and information on CIA operatives might be in the CIA-agents category. So a user who is working on the design of the propulsor for the SSN-XX submarine may have a security level {Secret, {SSNXX-propulsor, acoustics}} (because propulsors are designed to be quiet the design is also in the acoustics category), while the location of CIA operatives may have a security level {Top Secret, {CIA-agents}}.

 

With the use of categories, we need to refine our rules for information access.  We clearly want to continue the requirement that a user may only see information at or below her clearance level.  Additionally, he or she should only see information in a category for which she is cleared.  The MLS model uses the dominates relation to determine information access.  Let L(A)={CA,ϕA} be the level of subject or object A and let L(B)={CB,ϕB}  be the security level of subject or object B.  Then L(A) dominates L(B) if and only if CA  ≥ CB and ϕB Í ϕA.  Stated less formally, when level High dominates level Low, the clearance (or classification) of High is above Low, and Low does not contain a category that is not also in High. 

 

The MLS model uses the dominates relation to establish rules that define when a subject may access an object with the goal to ensure no user has access to data for which she is not cleared.  When this model is first introduced, it is common only to think of controlling read access to the protected data, e.g., one may or may not read the nuclear launch codes.  Yet users access data in various modes. For example, they may write data as well as read it.  The access control system must mediate any type of access request in a way that meets the policy goal of never allowing a user to see data for which she is not cleared. 

 

The creators of this model (LaPadula 1975) imagined the following modes of access based on the ability to observe or alter an object:

 

1.    no observation and no alteration;

2.    observation and no alteration;

3.    alteration, but no observation; and

4.    both observation and alteration.

 

The first mode is denoted by e (execute), the second by r (read), the third by a (append), and the last by w (write).  

 

The envisioned modes correspond to the ways in which files are accessed.   For example, the process that authenticates a user may be able to read the password file, but this process should not modify the password file.  This corresponds to the read (r) mode. At the same time, when a user decides to change her password, the process that makes the change must both read and write the file; the file is first read to find the correct entry and then it is written with the new password.  This corresponds to the (w) mode. An append mode (a) is often used to add an entry to a system log, because the process that adds the new entry does not need to overwrite or delete previous entries and has no need to read other entries.  An executing user process does not ready the binary file from which it was created typically.   This would correspond with the (e) mode. Yet, some argue that execute access requires read.  This is in part because it is typically difficult or impossible to prevent an executing process from reading the code (or other segments) within its own memory.  So the ability to execute cannot be granted without also granting read access.

 

In order to enforce the requirement that no user see data for which he is not cleared, one might be tempted to apply the same restriction to write access that is applied to read access, that is, a user may write to objects at or below her security level.  Yet on a computer system, this means that a process could read information with a Top Secret classification and then write it to an object with an Unclassified classification, which would allow a user with only Unclassified clearance to see the Top Secret information. Clearly this threatens to bypass the intended restrictions of the clearance, classification scheme!

 

Description: Description: informationFlow.png

Figure 1: Information Flow

 

Notice that this naēve approach toward restricting writes fails because information flows through a combination of observations and alterations.  This is depicted in Figure 1 (LaPadula 1975). A malicious subject may use a sequence of observation and alteration to allow information to flow from a higher level to a lower level. 

 

Description: Description: :allowedFlow:Slide1.jpg

Figure 2: Access Allowed through Simple Security Condition

 

Hence we want to control both observation and alteration so that information can never flow down.  Information flow in this model is controlled by the following rules.

 

Simple Security Condition (SSC):  If subject S has observe access (r or w) to object O, then L(S) dominates L(O). 

 

The SSC ensures that no subject may observe data above his level directly.  Figure 2 shows the access that is allowed to a subject under the SSC.  The subject is at level Medium, where High > Medium > Low.  (The > symbol denotes ordering under the dominates relation.) Object Oh is at level High, Om is at level Medium and Ol is at level Low.

 

Notice that it is possible for the subject to read from Om and write the information to Ol.   Under the SSC restriction alone, a user might write to objects below his level.  Although the SSC restriction disallows a user to observe objects at a level higher than his own, a combination of reads and writes can allow information to effectively change levels, from a higher level to a lower level.  This has the potential to allow information to flow from higher levels to lower levels.

 

The creators of this model proposed the following additional controls to address this information flow.

 

*-Property[2]: If a subject S has simultaneous observe access (r or w) to object O1 and alter access (a or w) to object O2 then L(O2) dominates L(O1).

 

 

Description: Macintosh HD:Users:jmayo:Dropbox:acv:tutorials:MLS:old:allowedFlow:Slide4.jpg

 

 

Figure 3: Access Allowed through SSC and *-Property

The SSC and *-property together disallow a user to read data from an object at level LHIGH and then write that data to an object at level LLOW when LHIGH is at a higher level that LLOW.  This is depicted in Figure 3.  Part A of the figure depicts an observe access (read or write) by the subject to object Om, the highest level accessible to the subject.  Part B of the figure depicts the simultaneous access that would be allowed by the SSC and *-property. If the subject has observe (read or write access) to Om, then both write and append to Ol are not allowed because Ol does not dominate Om.  (The subject may both write and append Om because Om dominates Om.)

 

Does the *-Property disallow the subject from ever gaining write access to a file at level Low?  This could be problematic on a computer system since it means that there is no way to make a file both readable and writeable by a group of users at different security levels.  This would also mean that a General who operates at the Top Secret level could never edit a memo that could be read by his subordinates that operate at lower levels.

 

Notice that if a subject never observed Om, then it would be safe for the subject to both observe and alter Ol.  In this case, the subject is effectively operating at the lower level.  This is depicted in Figure 4.  In the figure, the subject is reading and modifying Ol at level Low.  Unless he reads Om or Oh, the information from these higher level objects cannot flow down. 

 

Description: Description: :allowedFlow:Slide4.jpg

Figure 4: Subject Access at Single Level Below Subject Clearance Level

In this case, however, the level of the subject is different from the one for which he was given clearance.  Application of the SSC should use the level at which he is operating, not the level at which he was given clearance.   If we can identify a safe way to allow the user to change his level, the SSC and *-property will enforce the access restrictions that are required to ensure information does not flow down. 

 

The model creators identified the following criteria for allowing a subject to change its level.  By their scheme, a subject has a maximum level (e.g., the one for which military clearance has been given) and a (lower) current level (the level at which a subject is operating and that is used to make access control decisions). When a subject S attempts to change its level to LNEW, the following requirements must be met.

 

1.    LMAX(S) dominates LNEW

2.    For every object OR for which S has read access, LNEW dominates L(OR)

3.    For every object OW for which S has write access, L(OW) dominates LNEW

 

Notice that this means whenever a subject gives up read access to an object O, the subject must no longer have access to any of the data associated with O, in memory, a file, or elsewhere.  This prevents the subject from reading data from an object OHIGH at level LHIGH, changing level to LLOW, where LHIGH > LLOW, and then writing the data to an object at level LLOW. An implementation must address precisely what the “simultaneous access”, disallowed by the *-property, means in terms of user actions.[3] 

 

The restrictions below restate the SSC and *-properties to incorporate a current and maximum subject level.

 

Simple Security Condition (SSC):  If subject S has observe access (r or w) to object O, then LCUR(S) dominates L(O). 

 

*-Property: If subject S has x access to object O, then

1.    L(O) dominates LCUR(S) if x is append;

2.    L(O) = LCUR(S) if x is write; and

3.    LCUR(S) dominates L(O) if x is read.

 

Level changes:  S at LCUR(S) request to change level to LNEW granted if:

 

1.    LMAX(S) dominates LNEW,

2.    for every object OR for which S has read access, LNEW dominates L(OR), and

3.    for every object OW for which S has write access, L(OW) dominates LNEW, then LCUR(S)=LNEW.

 

The restrictions we have discussed so far are mandatory controls.  The Bell-LaPadula model allows for a discretionary component.  This provides for a subject to be granted access so long as the mandatory controls are not violated.  The discretionary policy is represented with an access control matrix M.  Hence, at a high level, the requirement for subject S to gain x permission to object O is:  (1) the SSC is satisfied, (2) the *-property is satisfied and x is in M[S,O]. Notice that this discretionary component is an additional restriction that can never violate the SSC or *-property.  One might use the discretionary control to implement a more fine-grained policy than the SSC or *-property alone require. This tutorial does not consider the discretionary component from this point forward.

 

Also note that the model allows for a “trusted subject” that can violate *-property and write down, for example to facilitate system administration.

Specification

 

The beauty of a model is that it encapsulates the restrictions of a broad class of policies. So one can easily specify a given policy based on the rules given in the model.   Yet the model is not a policy in and of itself.  Under the MLS model, we specify a policy by assigning objects and users to security levels.  Access by these users to the specified objects will be determined by the SSC and *-property. 

 

As an example, consider a system that is used by engineers designing a submarine.  The system contains data on: the crew quarters, the operational limits of the submarine, the design of equipment modifications to keep the equipment quiet during operation, and data on the submarine propulsor.  The crew quarter information is all Unclassified and is in the category Quarters; the hydrodynamic data is Confidential and in the category Hydrodynamics; the equipment modification data is Secret and is in the category Acoustics; and the propulsor data is Top Secret and is in the categories Hydrodynamics and Acoustics (because propulsor noise will give away a submarine’s location so advanced technology is used to keep them quiet). 

 

Following is a specification for this policy (Policy 1). The policy is given in the specification language for MLSvisual.  You can download MLSvisual at: http://acv.cs.mtu.edu/MLSvisual.html.  A user manual is available on this same page.  In this policy, line numbers are given as a convenience and are not supported by the language. 

 

This policy contains four clearances/classifications: Unclassified, Confidential, Secret and TopSecret, using the clearances keyword, in line 2 of the specification. The < symbol indicates the order among clearances/classifications. There are three categories: Quarters, Hydrodynamics and Acoustics, assigned in line 3 using the categories keyword. The assign statement assigns classifications to objects.  A security level is a colon-separated list of first the clearance/classification followed the level’s categories. Line 5 assigns the level (Unclassified, {}) to all files beneath the root directory (due to the –r switch).  Line 9 assigns the level (Confidential), {hydrodynamics}) to the file /hydro/operatingEnvelope.  This overrides the level assignment given through the assignment at line 5, because the assignment through a longer prefix (/hydro/operatingEnvelope at line 08) will override the assignment it receives through a shorter prefix (/ at line 05). The user statement assigns security levels to users.  Line 11 assigns the level (TopSecret, {Acoustics}) to the users Alice and Bob. See the MLSvisual user guide for more information on MLSvisual syntax.

 

Text Box: 01   # Clearances
02   clearances:Unclassified<Confidential<Secret<TopSecret
03   categories:Quarters,Hydrodynamics,Acoustics
   
04   # Object Security Level Assignment
05   assign Unclassified: -r /
06   assign TopSecret:Hydrodynamics:Acoustics -r /propulsor
07   assign Secret:Acoustics -r /equipMods
08   assign Confidential:Hydrodynamics -r /hydro/operatingEnvelope
09   assign Unclassified:Quarters -r /quarters
      
10   # User Security Level Assignment
11   users TopSecret:Acoustics  Alice, Bob
12   users Secret:Hydrodynamics:Acoustics Cathy
12   users TopSecret:Hydrodynamics Cathy
01   users Confidential:	Dan
Policy 1

 

 

Figure 5 is a depiction of this policy in the General Graph of MLSvisual.  It is a Hasse Diagram of the partial order formed by the dominates relation on the security levels.

 

Figure 5: Hasse Diagram of Policy 1

 

 

Notice that the clearance/classification associated with a level is identified by its color and a number identifies a category, in order to reduce clutter in the graph.  The topmost node in this graph is red and is labeled (1,2,3).  This represents the security level (TopSecret,{Quarters, Hydrodynamics, Acoustics}).  In the graph, an icon represents each user and the icon appears next to the users security level. The icon is labeled with the user’s name.

 

Figure 6 shows the access that would be allowed to a subject operating at the level (TopSecret, {Hydrodynamics, Acoustics}).  Levels at which this subject could read an object are shown in orange, levels at which the subject could write an object are shown in blue.  (MLSvisual uses the term write to designate that an object may be modified.  In the terminology above, this is the “append” right.)

 

Description: Macintosh HD:Users:jmayo:Dropbox:acv:tutorials:MLS:accessTS-Acoustics-Hydro.tiff

Figure 6: Access Allowed by Subject at (TopSecret, {Hydrodynamics, Acoustics})

 

This figure illustrates why the model includes the ability for subjects to change levels.  Consider an object at the level (TopSecret,{Hydrodynamics, Acoustics}).  Suppose that two users, Dan and Eve, both must read and modify this object.  Then they must be at the same level as the object.  Now suppose there is a second object, that Dan must only write and Eve should only read.  In order for Dan to only be allowed modify the file, it must at a level that dominates his level. In the diagram of Figure 6, it must be at his level or above.  (In the diagram of Figure X, it must be at one of the levels in blue.) Yet in order for Alice to only read the file, it must be at a level dominated by her level.  (In the figure above, it must be at one of the orange levels.)  Hence, even relatively simple access requirements become difficult or impossible if a subject cannot change levels.  Note that the discretionary component of the model can address the requirement above.  Yet, discretionary systems may not meet the security requirements of an organization due to their discretionary nature.

 

 

Other Resources

 

This has been a high-level introduction to the MLS model.  Another good tutorial on MLS is available here: https://cryptosmith.com/mls/.  A more detailed and complete presentation of the model is available from the technical report that introduced the Bell-LaPadula model available here: http://csrc.nist.gov/publications/history/bell76.pdf. David Bell, one of the model authors, gives a retrospective on the model in the paper available here: https://www.acsac.org/2005/papers/Bell.pdf.

 

Works Cited

LaPadula, D.E. Bell and L. J. “Secure Computer System. Unified Exposition and Multics Interpretation.” MTR-2997. 1975 July.

 

 

 

 

 

 

 



[1] The term security level Is sometimes used to refer to either a clearance or classification, since they are drawn from the same set.  Here we use it to refer to a pair (clearance,category set),or (classification, category set).

[2] The name * property arose because one of the authors did not have a satisfying name for the property at the time it was to be discussed with his co-author.  A better name was never determined and the “placeholder” name persists.

[3] The mechanisms for implementing this requirement are dependent on the operating system and available hardware.  Techniques for implementation are beyond the scope of this tutorial.