# Mandatory Access Control
A *mandatory access control* (MAC) policy is a means of assigning access
rights based on regulations by a central authority. This class of
policies includes examples from both industry and government. The
philosophy underlying these policies is that information belongs to an
organization (rather than individual members of it), and it is that
organization which should control the security policy.
## Multi-level security (MLS)
In national security and military environments, documents are labeled
according to their *sensitivity* levels. In the US, these range from
*Unclassified* (anyone can see this) to *Confidential* to *Secret* and
finally (we believe) to *Top Secret*; other countries use similar
classifications. These levels correspond to the risk associated with
release of the information.
But it is not sufficient to use only sensitivity levels to classify
objects if one wants to comply with the *Need to Know* principle: access
to information should only be granted if it is necessary to perform
one's duties. (Need to Know is an instance of Least Privilege.)
*Compartments* are used to handle this decomposition of information.
Every object is associated with a set of compartments (e.g. crypto,
nuclear, biological, reconnaissance, etc.). An object associated with
{crypto, nuclear} may be accessed only by subjects who need to know
about both cryptography and nuclear weapons. An object associated with
the empty set {} simply doesn't pertain to any need-to-know
compartments.
A *label* is a pair of a sensitivity level and a set of compartments. A
document might have the label (Top Secret, {crypto,nuclear}) if it
contained extremely sensitive information regarding cryptography and
nuclear weapons. In practice, each paragraph in a document is assigned a
set of compartments and a sensitivity. The classification of the entire
document would then be the most restrictive classification given to a
paragraph in that document.
Users are also labelled according to their security *clearance*. A
user's clearance, just like a document's label, is a pair of a
sensitivity level and a set of compartments.
Typical DAC mechanisms, like access control lists and capabilities,
aren't adequate to enforce confidentiality (or integrity) in the MLS
setting. Consider the following example.
**Leakage through Trojan Horse.** A subject G is cleared at (Top
Secret, {}) because it runs on behalf of an army general. G has access
to object BP containing battle plans. BP is labeled (Top Secret, {}).
An attacker, who does not have access to BP, creates a Trojan Horse
program T that if executed does the following:
- Create a new object O.
- Grant G write access to O.
- Grant A read access to O, where A is subject that is running on
behalf of attacker.
- Copy BP into O.
Obviously, it doesn't do any good for the attacker to run T. But
suppose T also has other functionality—it's word processor, or a game
(Minesweeper?), or some other application that G might be interested
in running. Then A might be able to trick G into running T. When that
happens, A will get access to the contents of BP through O. DAC can't
stop that.
How can we prevent this kind of attack from violating MLS? We need a
different kind of mechanism than DAC. One famous solution comes from
Bell and LaPadula (1973). They gave a formal, mathematical model of
multi-level security. This model enforces the *BLP policy*:
**Information cannot leak to subjects who are not cleared for the
information.**
Given two labels L1 = (S1, C1) and L2 = (S2, C2), we write that L1 ⊑
L2—meaning that L1 is no more restrictive than L2—when
- S1 ≤ S2, where Unclassified ≤ Confidential ≤ Secret ≤ Top Secret,
and
- C1 ⊆ C2.
Notice that ⊑ is a partial order: it is possible to have two labels that
are incomparable (e.g. (secret, {crypto}) vs. (top secret, {nuclear}))
according to ⊑.
Let L(X) denote the label of an *entity* X, where an entity is either a
subject or an object. The *BLP security conditions* are:
- A subject S may read object O only if L(O) ⊑ L(S). In other words,
subjects are not allowed to "read up."
- A subject S may write object O only if L(S) ⊑ L(O). In other words,
a subject may not "write down."
Do the BLP security conditions enforce the BLP policy? Yes. First, note
that a subject can never directly read an object for which it is not
cleared. The first condition guarantees this. Second, a subject must
never be able to learn information about some highly-labeled object O by
reading another low-labeled object O'. Note that this is only possible
if some other subject first reads O then writes O'. By the two
conditions, a read then write by S entails L(O) ⊑ L(S) ⊑ L(O'). But then
O actually has a lower label than O', so no information can have leaked.
The above was considered a significant result when it first was proved.
But there are several problems with the BLP formulation of MLS. These
include:
- It is possible that the security level for an entity could be
changed in mid-operation. This change could violate the
information-flow constraints we wish to preserve.
- The model is concerned with only confidentiality, not integrity. For
example, subjects can "write up". Thus, a subject that cannot read
an object is permitted to make changes to that object; this is
called a "blind write". Yet it makes little sense to trust a subject
to modify the information contained in an object, if that subject is
not trusted to read the information contained in the object. Biba
(1977) shows how to handle integrity as a mathematical dual of
confidentiality.
- A subject S that wants to write object O is not allowed to do so if
L(O) ≰ L(S). The subject must login at a lower level than his or
her clearance. It is annoying for principals to be forced to decide,
at the time they login, what rights they will need. But it is also a
nice application of the Principle of Least Privilege.
- Some processes must be allowed to violate the BLP security
conditions. For example, an encryption program takes secret
information and outputs encrypted but unclassified information.
Similarly, to do accounting, programs that may access confidential
data produce summary (billing) information that is not confidential.
Such programs would seem to be violating the no "write down"
condition. The traditional solution is to create *trusted subjects*,
which are not restricted by the BLP security conditions. This
introduces a potential vulnerability into the system, however.
Some real-world systems, including SELinux and TrustedBSD, combine MAC
and DAC policies. In such cases, an operation is allowed only if both
the MAC policy and the DAC policy both permit the operation. RBAC and
groups are also employed alongside MAC.
## Brewer-Nash
MLS is appropriate for national security confidentiality policies, and
it is sometimes appropriate for business confidentiality policies.
Consider a microprocessor company's plans for its next-generation chip.
The company might consider these plans Top Secret and desire an access
control mechanism that can prevent leakage of this sensitive
information.
Other business confidentiality policies do not exhibit such close
correspondence to MLS. Consider an investment bank. It employs
consultants who both advise and analyze companies. When advising, such
consultants learn secret information about a company's finances that
should not be shared with the public. The consultant could exploit this
*insider information* while performing analysis, to profit either
himself or other clients. Such abuse is prohibited by law.
Brewer and Nash (1989) developed a MAC policy for this scenario, calling
it *Chinese Wall* by analogy to the Great Wall of China. The intuition
is that an unbreachable wall is erected between different parts of the
same company; no information may pass over or through the wall. In the
Brewer-Nash policy, we (as usual) have have objects, subjects, and
users. However, objects are now grouped into *company datasets* (CDs).
For example, an object might be a file, and a company dataset would then
be all of the files related to a single company. Company datasets are
themselves grouped into *conflict of interest classes* (COIs). For
example, one COI might be the set of all companies in the banking
industry, and another COI might be all the companies in the oil
industry.
The Brewer and Nash security conditions are
as follows. Note that these conditions require tracking the set of read
objects for each user and subject.
1. A subject S may read object O only if S has never read any object O'
such that:
* COI(O) = COI(O'), and
* CD(O) ≠ CD(O').
2. A subject S may write object O only if S has never read an object
O' such that CD(O) ≠ CD(O').
The first condition guarantees that a single user never breaches the
wall by reading information from two different CDs within the same COI.
The second condition guarantees that two or more subjects never
cooperatively breach the wall by performing a series of read and write
operations. How would a cooperative breach work?
**Cooperative breach:** Suppose S1 has read from CD1, and S2 has read
from CD2, where CD1 and CD2 are both in COI1. Then:
1. S1 reads information from an object in CD1.
2. S1 writes that information to object O in CD3 in COI2.
3. S2 reads that information from O.
S2 now has read information about both CD1 and CD2, which violates the
Brewer-Nash policy.
Condition 2a prevents the write operation in step (ii) above by
restricting when a subject may write: once a subject reads two objects
from different CDs, that subject may never write any object.
There's still a problem—all this assumes the user can't store
information outside the system (e.g., in their brain). In that case,
even 2a wouldn't suffice. So this policy really isn't used to constrain
the activity of humans so much as the activity of potentially malicious
programs.
## Exercises
1. A fictitious microprocessor company called Mintel, Inc., is implementing a MLS
model for its computer systems. The security officer of Mintel proposes the following
labels for users and objects:
* Alice is the CEO of Mintel. L(Alice) = (Top Secret, {NewCPU,HR})
* Bob is a manager in the HR office. L(Bob) = (Secret, {HR})
* Cindy is a scientist working on a part of a new CPU product.
L(Cindy) = (Secret, {NewCPU})
* Dave is a receptionist in the main lobby. L(Dave) = (Unclassified, {})
* payroll.xlsx is a spreadsheet containing salary information.
L(payroll.xlsx) = (Confidential, {HR})
* strategy.pptx is a briefing on Mintel’s strategy for its new CPU product.
L(strategy.pptx) = (TopSecret, {NewCPU})
* index.php is the homepage of Mintel’s website. L(index.php) = (Unclassified, {})
Using the BLP security conditions, enter an 'r' in the following table if a subject may
read an object, and a 'w' if a subject may write an object. Assume that each user logs
in with their full clearance enabled, hence the subject executing on the user’s behalf
has the full clearance of the user.
| payroll.xlsx | strategy.pptx | index.php |
Alice/Etrade.exe | | | |
Bob/Solitaire.app | | | |
Cindy/emacs | | | |
Dave/IE.exe | | | |
2. Consider the database of an investment firm Invy. Analysts employed by Invy use the
database to guide the investments of companies and individuals. The Invy database
contains records for the following companies:
* Banks:
- Bank of America
- Citibank
- PNC
* Oil companies:
- ExxonMobil
- BP
- Chevron
Invy uses a Brewer-Nash policy in which the banks are one COI and the oil companies
are another COI.
Anthony is a new analyst at Invy. He is assigned to counsel Citibank on its
investments. He logs in and begins to familiarize himself by reading from the
database records pertaining to Citibank.
* After doing so, what companies can Anthony read from according to the Brewer-Nash
security conditions?
* What companies can Anthony write to according to the Brewer-Nash security
conditions?
* In the same session, Anthony also reads some records pertaining to BP. Now what
companies can he read and write?
* What is the minimum number of analysts Invy must employ, assuming that the
database contains only those companies listed above, and that every company is
assigned to at least one analyst?