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
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!
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
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).
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.
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.
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.)
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.