Tutorial 3.11: Mandatory Access Control (MAC)

Learning Objectives

After completing this tutorial, you should be able to:

• Define Mandatory Access Control (MAC) and distinguish it from Discretionary Access Control (DAC).
• Explain the concepts of security labels, classification levels, and clearance.
• Describe the Bell-LaPadula model and its properties (Simple Security, *-Property, and Discretionary Security).
• Analyze the Biba model and its focus on integrity.
• Compare Bell-LaPadula and Biba, understanding their complementary roles.
• Evaluate MAC implementations such as SELinux and AppArmor.
• Assess the advantages and limitations of MAC in different contexts.
• Design a MAC policy for a high-security environment, considering labeling and enforcement.
• Analyze real-world use cases where MAC is essential.

Overview

In Tutorial 3.10, we examined Discretionary Access Control (DAC), where the owner of a resource has discretion over access. While DAC is flexible and intuitive, it has significant limitations, particularly the Trojan horse problem and the inability to enforce a consistent security policy across an organization. Mandatory Access Control (MAC) addresses these shortcomings by placing authority in a central administrator who sets immutable policies based on security labels and classifications.

MAC is a model where access decisions are determined by a central authority according to a set of rules that cannot be overridden by users or owners. In MAC, every subject and object is assigned a security label (e.g., classification level, clearance, categories). Access is granted only if the labels satisfy the policy rules. This ensures strict information flow control, making MAC ideal for high-security environments such as military, government, and critical infrastructure.

This tutorial provides a comprehensive exploration of MAC. We begin by defining MAC and its foundational concepts, including security labels, classification levels, and clearance. We then delve into two classic formal models: the Bell-LaPadula model, which focuses on confidentiality, and the Biba model, which focuses on integrity. We analyze their rules and properties—the Simple Security Property, the *-Property (Star Property), and the Discretionary Security Property for Bell-LaPadula, and the corresponding rules for Biba.

We compare and contrast these models, highlighting their complementary roles: Bell-LaPadula prevents unauthorized reading of sensitive information (no read up, no write down), while Biba prevents corruption of high-integrity data (no write up, no read down). We discuss the practical applications of each model and how they can be combined.

We then survey real-world MAC implementations, focusing on SELinux (Security-Enhanced Linux) and AppArmor, which are the two most prominent MAC frameworks in Linux. We examine their architectures, policy languages, and typical use cases. We also discuss the advantages of MAC—strong security, centralized control, resistance to user errors—and its limitations—complexity, administrative overhead, and potential for misconfiguration.

The tutorial concludes with case studies illustrating MAC in a military intelligence system and a healthcare environment where integrity is paramount. These examples demonstrate the practical application of MAC principles and the trade-offs involved in deploying such systems.

By the end of this tutorial, you will have a thorough understanding of MAC, enabling you to evaluate when and how to apply it, and to recognize the critical role it plays in protecting highly sensitive or high-integrity systems.

1. Introduction to Mandatory Access Control

1.1 Definition and Core Principle

Mandatory Access Control (MAC) is an access control model in which access decisions are made by a central authority based on a set of system-wide policies. These policies are mandatory and cannot be overridden or modified by users, even the owners of objects. In MAC, every subject (user, process) and object (file, device) is assigned a security label that includes a classification level and possibly other attributes. Access is allowed only if the labels meet the policy's rules (e.g., subject's clearance is at least the object's classification).

The "mandatory" aspect means that the policy is enforced by the system and cannot be bypassed. This is in stark contrast to DAC, where the owner has discretion. MAC is used in environments where a consistent, global security policy is required and where the risk of unauthorized access or data leakage is very high.

1.2 Historical Context

MAC has its roots in military and government security requirements, particularly the U.S. Department of Defense's (DoD) Trusted Computer System Evaluation Criteria (TCSEC), also known as the Orange Book. The Orange Book defined requirements for mandatory protection, including the use of security labels and the enforcement of information flow policies. The Bell-LaPadula model was developed in the 1970s to formalize the confidentiality requirements of MAC. Later, the Biba model addressed integrity. MAC has since been implemented in many operating systems, including security-enhanced Linux (SELinux), Trusted Solaris, and various military-grade systems.

1.3 Key Concepts: Labels, Clearance, and Classification

• Security Label: A marker assigned to a subject or object that indicates its security attributes. Labels typically consist of a classification level (e.g., Top Secret, Secret, Confidential, Unclassified) and a set of categories (e.g., NATO, Nuclear, Cryptographic).
• Clearance: The level of trust or authorization assigned to a subject (usually a user). A user with a given clearance can access objects at or below that classification, subject to category restrictions.
• Classification: The sensitivity level assigned to an object. It indicates the degree of harm that could result from unauthorized disclosure.
• Categories: Compartments that further restrict access based on need-to-know (e.g., "Personnel", "Finance", "Operations").

In MAC, the system enforces rules based on these labels. For example, a subject with clearance "Secret" and categories {NATO, Crypto} can read objects classified as "Secret" or lower, but only if the object's categories are a subset of the subject's categories.

2. Security Labels and Classifications

2.1 Classification Hierarchies

Classification levels are typically ordered in a hierarchy from lowest to highest. Common DoD classifications include:

• Unclassified (U)
• Confidential (C)
• Secret (S)
• Top Secret (TS)

Each level includes all lower levels, so a Top Secret clearance allows access to Secret, Confidential, and Unclassified objects (subject to category restrictions). The hierarchy ensures that the more sensitive the data, the higher its classification and the more restricted its access.

2.2 Categories and Compartments

Categories are non-hierarchical tags that represent areas of interest or specific projects. They are used to implement need-to-know. For example, a user might have clearance Top Secret with categories {NATO, Crypto}. This user can access objects with classification Top Secret or lower, but only if the object's categories are a subset of the user's categories. Thus, the user cannot access a Top Secret document classified with {NATO, Crypto, Personnel} because "Personnel" is not in their set.

2.3 Labeling Subjects and Objects

In a MAC system, every subject (user process) and object (file, device, etc.) must have a security label. The label is often stored in the object's metadata (e.g., extended attributes in a file system). The operating system's reference monitor checks these labels on every access request.

2.4 Example Labels

Entity	Label
User Alice	Clearance: Secret; Categories: {NATO}
User Bob	Clearance: Top Secret; Categories: {Crypto, NATO}
File A	Classification: Secret; Categories: {NATO}
File B	Classification: Top Secret; Categories: {Crypto}

In this example, Alice can read File A (since her clearance is Secret, and her categories include NATO). She cannot read File B because her clearance is not Top Secret. Bob can read both File A and File B. If File B had categories {Crypto, NATO}, Bob could read it because his categories are a superset.

3. The Bell-LaPadula Model

3.1 Overview

The Bell-LaPadula (BLP) model is a formal security model developed in 1973 by David Bell and Leonard LaPadula. It is a state-machine model that focuses on preserving confidentiality. It is designed to prevent unauthorized disclosure of information by enforcing information flow from lower security levels to higher ones. BLP was developed for the U.S. Department of Defense and is the foundation for many MAC implementations.

3.2 Security Properties

The BLP model defines three main properties:

• Simple Security Property (SS Property, "no read up"): A subject can read an object only if the subject's clearance is at least the object's classification (i.e., subject's label dominates object's label). This prevents a subject from reading information at a higher classification than they are cleared for.
• *Property (Star Property, "no write down"): A subject can write to an object only if the object's classification is at least the subject's clearance (i.e., object's label dominates subject's label). This prevents a subject from writing sensitive information to a lower classification object, which could lead to disclosure.
• Discretionary Security Property: Access is further restricted by discretionary access control (DAC) rules (e.g., ACLs). This property allows the owner to add additional restrictions beyond the mandatory ones.

The key insight is that information flows upward, from lower classifications to higher classifications. A subject with a higher clearance can read lower-classified data, but cannot write down to lower levels, preventing leakage.

3.3 Formal Description

In BLP, each subject and object has a security label consisting of a classification level and a set of categories. The dominance relation (≥) is defined as follows:

• A label L1 dominates L2 (L1 ≥ L2) if the classification of L1 is at least that of L2, and the category set of L1 is a superset of L2's categories.

The SS property: subject can read object iff the subject's label dominates the object's label. The *Property: subject can write to object iff the object's label dominates the subject's label.

3.4 Example

Consider a subject with label (Secret, {NATO}) and an object with label (Unclassified, {}).

• SS Property: Subject's label (Secret) dominates object's label (Unclassified), so read is allowed.
• *-Property: Object's label (Unclassified) does not dominate subject's label (Secret), so write is not allowed. The subject cannot write Secret-level information to an Unclassified object.

Now consider an object with label (Top Secret, {NATO, Crypto}). Subject's label does not dominate object's label (Top Secret > Secret), so read is not allowed. Write: object's label dominates subject's label, so write is allowed. The subject can write to a higher classification object (which is permissible because it doesn't leak sensitive data).

4. The Biba Model

4.1 Overview

The Biba model was developed by Kenneth J. Biba in 1977 as a complementary model to Bell-LaPadula, focusing on integrity rather than confidentiality. The Biba model is designed to prevent data corruption by ensuring that information flows from higher integrity levels to lower integrity levels, preventing untrusted subjects from corrupting high-integrity data.

4.2 Integrity Labels

In the Biba model, subjects and objects are assigned integrity labels that indicate their level of trustworthiness or correctness. Higher integrity labels indicate more reliable or verified data. For example, a system might have integrity levels: High, Medium, Low.

4.3 Biba Properties

The Biba model defines three properties analogous to BLP but reversed:

• Simple Integrity Property ("no read down"): A subject can read an object only if the subject's integrity level is at least the object's integrity level (i.e., subject's integrity dominates object's integrity). This prevents a subject from reading data at a lower integrity level, which could corrupt their processing (e.g., a high-integrity process reading low-integrity input).
• Integrity *-Property ("no write up"): A subject can write to an object only if the object's integrity level is at least the subject's integrity level (i.e., object's integrity dominates subject's integrity). This prevents a subject from writing to a higher integrity object, which could corrupt it.
• Invocation Property: A subject can invoke another subject (e.g., call a program) only if the invoked subject's integrity is at least the invoking subject's integrity (or vice versa, depending on the variant).

In essence, Biba ensures that data flows from high integrity to low integrity, preventing low-integrity data from affecting high-integrity processes.

4.4 Example

Consider a subject (process) with integrity level High, and an object (file) with integrity level Low.

• Simple Integrity: Subject High ≥ Object Low, so read is allowed. The high-integrity process can read low-integrity data (but this might be risky; Biba allows it but recommends caution).
• Integrity *-Property: Object Low ≥ Subject High? No. So the subject cannot write to the low-integrity object. This prevents the high-integrity process from corrupting low-integrity data with its output? Actually, Biba says write is allowed only if object's integrity ≥ subject's integrity, so a High subject cannot write to a Low object. This is the "no write down" for integrity (opposite to BLP). Wait, careful: Biba's *-property is "no write up" – a subject can only write to objects with integrity ≥ its own. So High subject cannot write to Low object. That prevents high-integrity data from being placed in a low-integrity context where it could be corrupted later.

Note: The Biba model is less widely deployed than Bell-LaPadula but is important for integrity-critical systems.

5. Comparison of Bell-LaPadula and Biba

Aspect	Bell-LaPadula (Confidentiality)	Biba (Integrity)
Goal	Prevent unauthorized disclosure of information	Prevent unauthorized modification or corruption
Label Focus	Classification (Confidentiality level)	Integrity level
Read Rule	No read up (subject can only read at or below its clearance)	No read down (subject can only read at or above its integrity level)
Write Rule	No write down (subject can only write at or above its clearance)	No write up (subject can only write at or below its integrity level)
Information Flow	Flows upward (low to high)	Flows downward (high to low)
Common Use	Military, government, data confidentiality	Financial systems, data integrity, healthcare

In practice, a system might use both models by assigning both confidentiality and integrity labels to subjects and objects, enforcing both sets of rules. This is often referred to as a multilevel security system. However, the combined rules can be restrictive and require careful design.

6. MAC Implementations: SELinux and AppArmor

6.1 SELinux (Security-Enhanced Linux)

SELinux is a Linux kernel security module that implements Mandatory Access Control. It was developed by the U.S. National Security Agency (NSA) and released as open source. SELinux uses a flexible policy language based on Type Enforcement (TE) and Role-Based Access Control (RBAC) within a MAC framework. It labels subjects and objects with security contexts that include user, role, type, and level.

Key features:

• Type Enforcement: Each process (subject) has a type (domain), and each file has a type. Policies define which domains can access which file types (e.g., read, write, execute).
• Role-Based Access Control: Users are assigned roles, and roles can be confined to specific domains.
• Multilevel Security (MLS): SELinux supports the Bell-LaPadula model for confidentiality by adding security levels and categories.
• Policy flexibility: Policies can be targeted (confining specific services) or strict (confining everything).

SELinux is complex but provides fine-grained control over system resources, making it suitable for high-security environments like military systems, government servers, and critical infrastructure.

6.2 AppArmor

AppArmor is another Linux MAC implementation, but it is simpler and easier to use than SELinux. AppArmor uses path-based access control rather than labeling. It confines applications (profiles) to a set of files and permissions. AppArmor is included in many Linux distributions (Ubuntu, SUSE) and is popular for securing network services like web servers, databases, and email servers.

Key features:

• Profiles: Each application has a profile that defines what files and capabilities it can access.
• Complain mode: Allows violations to be logged without blocking, useful for developing profiles.
• Easy to write: Profiles are written in a simple syntax and can be generated automatically.

AppArmor is less granular than SELinux but is more accessible and requires less administrative overhead.

6.3 Comparison of SELinux and AppArmor

Aspect	SELinux	AppArmor
Labeling	Labels every object (files, processes, sockets)	Path-based; no labeling; associates profiles with applications
Complexity	High; steep learning curve	Low; easier to manage
Policy Language	TE, RBAC, MLS; complex	Simple profile syntax
Use Cases	High-security, military, government	Web servers, databases, enterprise applications
Adoption	Red Hat, CentOS, Fedora	Ubuntu, SUSE, Debian

7. Advantages and Limitations of MAC

7.1 Advantages

• Strong, consistent security policy: Policies are system-wide and cannot be bypassed by users or owners.
• Protection against Trojan horse attacks: Even if a user executes a malicious program, the program is subject to the MAC policy and cannot exceed the user's clearance or access objects outside its allowed domains.
• Information flow control: Prevents data leakage (Bell-LaPadula) and data corruption (Biba).
• Auditability: MAC policies are well-defined and can be audited more effectively.
• Resistance to user errors: Users cannot inadvertently change permissions to grant unauthorized access.
• Supports classification and need-to-know: Enables strict control over sensitive data based on clearances and categories.

7.2 Limitations

• Complexity: MAC policies, especially in SELinux, are complex to design, implement, and maintain.
• Administrative overhead: Requires skilled administrators and significant effort to manage labeling and policies.
• Rigidity: MAC policies can be too restrictive, hindering productivity and requiring frequent exceptions.
• Potential for misconfiguration: Incorrect labels or policies can cause system failures or security holes.
• Not suitable for all environments: In dynamic, agile organizations, MAC may be overly burdensome.
• Limited support for dynamic trust: MAC is based on static labels; it does not easily adapt to changing contexts or risk levels.

8. Security Considerations and Best Practices

8.1 Designing a MAC Policy

• Start with a clear security policy statement: define the confidentiality and integrity requirements.
• Identify all subjects (users, processes) and objects (files, devices, network ports).
• Assign appropriate security labels (classification, categories, integrity levels).
• Define the rules for read and write based on the chosen models (Bell-LaPadula for confidentiality, Biba for integrity).
• Implement the policy in a test environment and validate it before deployment.
• Use a phased approach: start with a permissive mode (e.g., SELinux permissive or AppArmor complain) to log violations and refine policies.
• Regularly review and update policies to reflect changes in the environment and threats.

8.2 Common Pitfalls

• Overly restrictive policies: Can break legitimate applications. Always test thoroughly.
• Under-specification: Missing labels or too few categories can lead to insufficient protection.
• Ignoring audit logs: MAC systems generate extensive logs; neglecting to monitor them can hide attacks or misconfigurations.
• Not updating policies: As systems evolve, policies must be updated to cover new services and changes in data sensitivity.

8.3 Integration with Other Controls

MAC is often used in conjunction with DAC, RBAC, and ABAC. For example, SELinux can enforce MAC while allowing DAC (via POSIX ACLs) for additional flexibility. MAC provides the baseline mandatory controls, while other models handle finer-grained or dynamic permissions.

9. Case Studies

9.1 Case Study: Military Intelligence System

Background: A defense intelligence agency operates a classified information system that stores intelligence reports, satellite imagery, and operational plans. The system must comply with DoD security requirements and enforce strict need-to-know and classification controls.

Solution:

• MAC Model: Bell-LaPadula for confidentiality.
• Labels: Subjects (users) have clearances (Top Secret, Secret, Confidential) and categories (e.g., Imagery, HumanIntel, CyberOps). Objects are similarly labeled.
• Enforcement: SELinux with MLS (Multi-Level Security) enabled. Policies enforce no read-up and no write-down.
• Auditing: All access attempts are logged; violations trigger alerts.
• Integration: DAC (ACLs) used for additional owner-controlled sharing within the same classification level.

Outcome: The system successfully prevents unauthorized disclosure and ensures that intelligence analysts only see information they are cleared for. The system is resilient to Trojan horse attacks because even if a user runs malicious code, it cannot elevate privileges or leak data.

9.2 Case Study: Healthcare Integrity System

Background: A hospital's electronic health record (EHR) system must ensure the integrity of patient records. Incorrect or altered data could lead to serious medical errors. The system must prevent unauthorized modifications and ensure that data entered by trusted clinicians is not corrupted by lower-integrity processes.

Solution:

• MAC Model: Biba model for integrity.
• Labels: Integrity levels: High (clinicians, verified data), Medium (admins), Low (external systems).
• Enforcement: AppArmor or SELinux with integrity policies. Simple Integrity: no read down (High cannot read Low) to prevent low-integrity data from influencing clinical decisions. Integrity *-Property: no write up (Low cannot write to High) to prevent corruption.
• Auditing: All modifications are logged; integrity violations are reported.

Outcome: Patient data integrity is maintained. Low-integrity processes (e.g., external lab feeds) are confined and cannot alter high-integrity records. The system provides strong assurance against data corruption.

10. Summary and Transition

This tutorial provided a comprehensive exploration of Mandatory Access Control (MAC). We defined MAC as a model where access decisions are made by a central authority using system-wide policies and security labels that are mandatory and non-overridable. We discussed the key concepts of security labels, classification levels, and clearance, and introduced the Bell-LaPadula model (confidentiality) and the Biba model (integrity), analyzing their properties and rules.

We compared Bell-LaPadula and Biba, highlighting how they complement each other: Bell-LaPadula prevents reading sensitive data (no read up) and writing down (no write down), while Biba prevents reading low-integrity data (no read down) and writing up (no write up). We then examined real-world MAC implementations in Linux: SELinux (complex, label-based, flexible) and AppArmor (simpler, path-based, easier to manage).

We evaluated the advantages of MAC—strong, consistent security, resistance to Trojan horses, and information flow control—as well as its limitations, including complexity, administrative overhead, and rigidity. We discussed best practices for designing and deploying MAC policies, including starting with a permissive mode, regular auditing, and integration with other controls.

The case studies illustrated MAC in a military intelligence system (Bell-LaPadula) and a healthcare integrity system (Biba), demonstrating how MAC is applied in practice to meet specific security requirements.

MAC provides a powerful tool for environments where confidentiality or integrity is paramount. However, its rigidity and complexity mean it is not suitable for all contexts. In the next tutorial, Tutorial 3.12, we will explore Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC), which offer more flexible and scalable approaches to access control while still providing strong security enforcement.

Quiz

Answer the following questions to check your understanding. Click the "Answer" button to reveal the solution.

Exercises

These exercises are designed to help you apply the concepts from this tutorial. Attempt each exercise before revealing the sample solution.

Homework

These homework questions require deeper analysis, research, and application. Answer each question comprehensively.

Summary

This tutorial provided a comprehensive exploration of Mandatory Access Control (MAC). We defined MAC as a model where access decisions are made by a central authority based on system-wide policies and security labels that are mandatory and non-overridable. We introduced the key concepts of security labels, classification levels, categories, and clearance, and examined two classic formal models: the Bell-LaPadula model (confidentiality) and the Biba model (integrity).

We analyzed the properties of Bell-LaPadula—Simple Security (no read up), *-Property (no write down), and Discretionary Security—and compared them with Biba's Simple Integrity (no read down) and Integrity *-Property (no write up). We discussed how these models can be used together to enforce both confidentiality and integrity in multilevel security systems.

We surveyed real-world MAC implementations: SELinux (complex, label-based, flexible) and AppArmor (simpler, path-based), highlighting their strengths and typical use cases. We evaluated the advantages of MAC—strong, consistent security, resistance to Trojan horses, and information flow control—and its limitations, including complexity, administrative overhead, and rigidity.

The case studies illustrated MAC in a military intelligence system (Bell-LaPadula) and a healthcare integrity system (Biba), demonstrating how MAC is applied in practice to meet specific security requirements. We also discussed best practices for designing and deploying MAC policies, emphasizing testing, auditing, and integration with other controls.

MAC provides a powerful tool for environments where confidentiality or integrity is paramount. However, its rigidity and complexity mean it is not suitable for all contexts. In the next tutorial, Tutorial 3.12, we will explore Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC), which offer more flexible and scalable approaches to access control while still providing strong security enforcement.

© 2026 COMP400 – Computer and Network Security • School of Computing and Information Systems, TrustOpen University • Unit 3: Authentication and Access Control