Part 1: Protection and Hardware Support for Access Control
Part 2: Discretionary Access Control
Part 3: Mandatory Access Control
Part 4: RBAC, ABAC, and Chinese Wall

Mandatory Access Control

Discretionary Access Control (DAC) gives users the freedom to manage access to their own resources. While convenient, it is fragile in environments that require containment of information according to organizational policy.

If users can share files with anyone, or if a compromised program can copy data to public areas, no system-level assurance of confidentiality or integrity exists. To address this, researchers developed Mandatory Access Control (MAC) systems in the 1970s, designed for environments where security policy must be centrally enforced and cannot be overridden by individual users.

In a MAC system, access decisions depend on security labels assigned to both subjects and objects. The system enforces a global policy that governs which labels can interact. The policy is not discretionary: even the owner of a file cannot make it readable by someone lacking the proper clearance. This approach was formalized through mathematical models of confidentiality and integrity.

Multilevel Security and the Bell–LaPadula Model

The first widely adopted MAC framework was the Bell–LaPadula (BLP) model, developed in the early 1970s for the U.S. Department of Defense.

Its purpose was to protect classified data stored on shared computers. Bell and LaPadula modeled security as a hierarchy of classification levels: Unclassified, Confidential, Secret, and Top Secret. Subjects (users or processes) are assigned clearances, while objects (files or data) are assigned classifications.

The model’s goal is confidentiality: preventing information from flowing from higher to lower levels. It defines three formal properties:

1. Simple Security Property (no read up)
   Named because it restricts “simple” read access.
   A subject may read an object only if its clearance is equal to or higher than the object’s classification. A Secret-cleared user can read Secret and Confidential data but not Top Secret data.

2. Star (∗) Property (no write down)
   Named for the asterisk symbol used in the original papers and defines the write rule.
   A subject may write to an object only if the object’s classification is equal to or higher than the subject’s clearance. This prevents high-level information from being written into lower-level files where it could leak.

3. Discretionary Security Property
   Named because it covers traditional per-object access controls.
   Within the bounds of the mandatory rules, discretionary controls (like file ACLs) may still apply, but they cannot override the mandatory restrictions.

Together, these rules create a one-way flow of information from lower to higher. A user can move data up the classification hierarchy but never down.

Example: Classified Document Handling

Consider an analyst cleared for Secret who accesses three files:

The analyst can read or edit documents at or below their level but cannot read higher-level documents or write lower-level ones.

Implementation and Limitations

Military and intelligence systems implemented Bell–LaPadula through multi-level secure (MLS) operating systems and databases. These systems label each file and process with a classification level and enforce access rules in the kernel. Examples include early versions of Multics, the Honeywell SCOMP system, and later government-evaluated systems under the Trusted Computer System Evaluation Criteria (TCSEC), known as the Orange Book.

Although effective for confidentiality, Bell–LaPadula has practical limitations:

• It makes collaboration across levels difficult. A “Top Secret” user cannot easily share sanitized information with a “Secret” user without special downgrading mechanisms.

• It does not address data integrity; low-quality data could flow upward freely.

• It fits hierarchical organizations well, but not flexible commercial environments.

Multilateral Security and the Lattice Model

The Bell–LaPadula model handles vertical separation of data—information at different classification levels. Real organizations, however, often require horizontal separation as well. Two analysts may both hold Top Secret clearance but should not have access to each other’s projects. The solution is multilateral security, which extends multilevel security by dividing each classification level into compartments that represent separate domains of information.

Compartments and Need-to-Know

Each classification level is subdivided into compartments that correspond to specific programs or projects. A user must not only have the appropriate clearance but also authorization for the compartment in question.

For example:

• A file labeled {Top Secret, Nuclear} can be accessed only by users cleared for Top Secret and authorized for the Nuclear compartment.

• Another file labeled {Top Secret, Signals} requires the Signals compartment.

• A user cleared for {Top Secret, Nuclear} cannot read {Top Secret, Signals} data even though both are Top Secret.

This approach captures the need-to-know principle, ensuring that access within the same classification level remains restricted to those who require it.

The Lattice Model of Security

To formalize both classification and compartmentalization, researchers developed the Lattice Model of Security. A lattice defines a partial ordering of labels. Each label consists of a classification level and a set of compartments. One label dominates another if its classification level is greater or equal and its compartment set includes the other’s.

In this model:

• A subject with label {Secret, {A, B}} can read {Confidential, {A}} because Secret ≥ Confidential and {A, B} ⊇ {A}`: The file is at a lower level and has a subset of the components.

• A subject with {Secret, {A}} cannot read {Secret, {B}}. They are incomparable because they are at the same level but different compartments: neither dominates the other.

This model allows precise definition of allowable information flows. Subjects may read from and write to objects according to dominance rules: information can only move from lower to higher labels in the lattice. The dominance relation can be visualized as a directed graph showing which subjects may access which objects.

Practical Challenges

While powerful, the lattice model introduces significant complexity:

• The number of label combinations grows rapidly with the number of compartments.

• Managing clearances and compartment authorizations for users and files is administratively burdensome.

• Collaboration across compartments is constrained: combining data from {Top Secret, Nuclear} and {Top Secret, Signals} requires creating a new compartment {Top Secret, Nuclear, Signals}.

• Many workflows require cross-compartment collaboration that the model forbids unless explicit policies are created to allow it.

Example: Government Use

The U.S. intelligence community uses this approach for Top Secret / Sensitive Compartmented Information (TS/SCI). Each compartment represents a particular intelligence domain, such as Signals Intelligence (SIGINT) or Human Intelligence (HUMINT). Analysts may have access to several compartments but not necessarily all.

Systems enforcing this policy require kernel-level label checks for both classification and compartment membership.

Limitations and Summary

Multilateral security and the lattice model strengthen confidentiality but increase rigidity and administrative cost. They prevent unintended sharing even among highly trusted users but make authorized collaboration cumbersome. As a result, they are primarily used in government or defense settings where strict compartmentalization outweighs convenience.

These concepts extend Bell–LaPadula’s confidentiality model. They focus exclusively on secrecy and the need-to-know principle, not on the trustworthiness of data. Integrity concerns require a different approach, which was addressed later by Kenneth Biba in his integrity model.

The Biba Integrity Model

Kenneth Biba introduced a complementary model in 1977 focused on integrity rather than confidentiality. While Bell–LaPadula prevents leaking secrets to lower levels, Biba prevents contamination of high-integrity data by untrusted sources.

The Biba model defines integrity levels, such as Low, Medium, and High, and reverses the Bell–LaPadula rules:

1. Simple Integrity Property (no read down)
   A subject cannot read data from a lower integrity level: this prevents trusted processes from being corrupted by untrusted input.

2. Star (∗) Integrity Property (no write up)
   A subject cannot write to data at a higher integrity level. This ensures that untrusted processes cannot modify trusted data.

To summarize:

• Bell–LaPadula: no read up, no write down (protects confidentiality)

• Biba: no read down, no write up (protects integrity)

Example: Healthcare Records

Suppose a hospital information system classifies data by integrity:

• High integrity: verified medical records

• Medium integrity: clinical notes

• Low integrity: patient-submitted data

A doctor (high integrity) can read and update medical records, but cannot import data directly from unverified patient submissions (no read down).

A patient (low integrity) can submit forms but cannot modify official records (no write up). This preserves the trustworthiness of critical data.

Real-World Use: Microsoft Mandatory Integrity Control

Microsoft implemented the Biba model’s core idea of integrity levels in Windows Vista through a mechanism called Mandatory Integrity Control (MIC). It introduced four integrity levels—Low, Medium, High, and System—and enforced a simplified version of Biba’s no write up rule.
Low-integrity processes, such as a web browser handling untrusted data, could not modify higher-integrity objects like system files or registry entries.

In practice, MIC successfully limited write-based privilege escalation but introduced usability problems. Many legacy applications assumed they could write to shared areas such as Program Files or the system registry. When Windows relabeled those areas as higher integrity, ordinary applications lost write access and began failing unless users elevated them with “Run as Administrator.”

Microsoft retained MIC as a kernel feature but made it one layer among several complementary mechanisms rather than the central enforcement point.

Starting with Windows 8, MIC was integrated into a broader sandboxing architecture called the AppContainer model. AppContainer enforces process isolation using a combination of:

• Discretionary Access Control (ACLs) for basic permissions,

• Integrity Levels (MIC) for mandatory write restrictions, and

• Capabilities declared in an app’s manifest that grant specific rights, such as file or network access.

Modern Windows applications—such as Microsoft Edge, Office Protected View, and UWP apps—run inside AppContainers, which still rely on MIC to prevent low-integrity content from modifying higher-integrity system areas.

The original no read down rule from Biba was never implemented. Windows uses MIC primarily to prevent upward writes, not to restrict downward reads. The design balances safety and compatibility: it confines untrusted data while preserving the ability of legitimate software to function without constant user elevation prompts.

Today, Windows continues to use integrity levels internally (you can view them with icacls), but most users interact with higher-level abstractions such as sandboxed applications, capability tokens, and virtualization-based isolation. MIC remains an essential kernel component, but it is now part of a layered security architecture rather than a standalone model.

Biba’s model is conceptually similar but enforces the opposite flow rules, but also less widely applied because commercial systems often require data to flow in both directions. In practice, Windows relaxed the strict “no read down” rule to improve usability.

Type Enforcement

As UNIX and Linux systems became more general-purpose, security designers sought a practical way to implement MAC without rigid classification levels. The Type Enforcement (TE) model emerged as a flexible mechanism to confine processes and control interactions between programs and resources.

Type Enforcement was first introduced in the 1990s in Honeywell’s LOCK system and later adopted by NSA’s SELinux (Security Enhanced Linux) project. Instead of using hierarchical labels like “Secret” or “Top Secret,” TE assigns each process a domain and each object a type. The security policy specifies which domains can access which types and with what permissions.

• Domains apply to subjects (processes).

• Types apply to objects (files, sockets, devices, etc.).

A simplified rule might say:

allow httpd_t httpd_sys_content_t:file { read getattr open };

This means processes in the httpd_t domain (web server) may read and open files labeled httpd_sys_content_t (web content), but nothing else.

Benefits of Type Enforcement

• Fine-grained control: every process and file can have its own label.

• Containment: if a process is compromised, its domain still restricts what it can access.

• Compatibility: TE works with existing UNIX permissions, adding a mandatory layer above existing controls.

Type Enforcement is the foundation of SELinux, which is now integrated into Red Hat Enterprise Linux, Fedora, Debian, and Android (as SEAndroid). It provides kernel-level enforcement of policy rules, confining even privileged processes.

Example: Web Server Isolation

A compromised web server running under SELinux might try to read /etc/shadow to harvest passwords (it is the counterpart to /etc/passwd, which contains user information such as ID, group, home directory, and shell; /etc/shadow stores the password hashes).

Without SELinux, file ownership and permissions might not stop it if the process runs as root. With SELinux, the process runs in domain httpd_t, and the policy simply denies any access to shadow_t objects. The kernel blocks the operation regardless of the user ID.

Limitations

Type Enforcement policies can be complex to author and maintain. Overly strict rules cause failures; overly broad ones weaken protection. Administrators often disable SELinux out of frustration with misconfigurations. Good tools and audit logs are essential to make TE manageable. Despite the learning curve, it remains the most practical form of MAC in general-purpose systems.

MAC in Perspective

Mandatory Access Control enforces a system-wide policy that users cannot override. Bell–LaPadula, Biba, multilateral lattice models, and Type Enforcement represent different approaches to that goal:

• Bell–LaPadula: keep secrets secret (confidentiality)

• Multilateral security and the lattice model: enforce need-to-know within the same level (compartmentalization)

• Biba: keep trusted data trustworthy (integrity)

• Type Enforcement: confine software to intended boundaries (isolation)

In contrast with DAC, MAC provides stronger assurance but at the expense of flexibility and usability. Real systems combine both: discretionary controls for user convenience and mandatory controls for critical subsystems.

Next: Part 4: RBAC, ABAC, and Chinese Wall