Mandatory access control is an access control model in which a central, system-wide security policy decides whether a subject such as a process may access an object such as a file, socket or device, and ordinary users and file owners cannot override that policy. In OS security, it adds a second, stricter layer on top of everyday file permissions, so that even a compromised program running as an administrator can be confined to what the policy allows.
The model originated in military and government systems that had to enforce classification levels, and it is now built into mainstream platforms: SELinux and AppArmor on Linux, the Mandatory Integrity Control labels in Windows, and the sandbox and System Integrity Protection mechanisms in macOS.
How mandatory access control enforces policy
Mandatory access control works by attaching security labels to subjects and objects and letting the kernel compare them on every relevant operation. A label may describe a type, a role, a sensitivity level or an integrity level. When a process tries to open, write, execute or connect, a reference monitor in the kernel checks the request against the loaded policy and either allows it or denies it.
The essential property is that the decision does not depend on who owns the object. Under classic permissions, the owner of a file may grant access to anyone. Under mandatory control, only the security administrator who writes the policy can change the rules, and the policy is typically loaded at boot and protected from modification at run time.
Both checks normally apply together. An action succeeds only if the ordinary permissions and the mandatory policy both allow it, so mandatory control can only restrict access further, never grant extra access.
Mandatory compared with discretionary access control
The difference between mandatory and discretionary access control lies in who holds the authority to grant access. The table compares the two models and the closely related role-based approach.
| Model | Who decides access | Typical mechanism | Main weakness |
|---|---|---|---|
| Discretionary (DAC) | The owner of the object | File permissions and access control lists | Malware inherits all of the user’s rights |
| Mandatory (MAC) | A central policy administrator | Kernel-enforced labels and rules | Complex policies and harder troubleshooting |
| Role-based (RBAC) | Administrators through assigned roles | Roles mapped to permissions | Role sprawl in large organizations |
The practical consequence is significant. Under discretionary control alone, any program a user runs can read everything the user can read. Under mandatory control, a web server or document viewer can be confined to only the files and ports its role requires, even when it runs with high privileges.
Policy models and labeling schemes
Mandatory access control is a family of models rather than one design, and each answers a different security goal. The classic models protect confidentiality or integrity, while modern desktop systems mostly use type enforcement to confine individual programs.
| Model | Protects | Core rule |
|---|---|---|
| Bell-LaPadula | Confidentiality | No read up, no write down |
| Biba | Integrity | No read down, no write up |
| Type enforcement | Program confinement | Allowed actions between domains and types |
| Multi-level security | Classified data separation | Sensitivity levels and categories on every object |
Labels can be assigned in two main ways. Label-based systems such as SELinux store a security context in each file’s extended attributes, so a renamed file keeps its label. Path-based systems such as AppArmor attach rules to file paths, which are easier to read and write but can behave unexpectedly when files are moved or linked.
Mandatory access control in desktop operating systems
Every major desktop operating system now includes some form of mandatory control, although the implementations differ greatly in scope and visibility. The table summarizes the main ones.
| System | Platform | Approach | Typical scope |
|---|---|---|---|
| SELinux | Fedora, Red Hat and Android | Label-based type enforcement | Whole system, fine-grained |
| AppArmor | Ubuntu, Debian and SUSE | Path-based profiles | Selected high-risk programs |
| Mandatory Integrity Control | Windows | Integrity levels on processes and objects | Browsers, sandboxes, elevated processes |
| macOS sandbox and SIP | macOS | Kernel policy modules and protected system paths | Apps from the store and system files |
Windows integrity levels, for example, run sandboxed browser components at low integrity, which prevents them from writing to most user files even though they run under the user’s account. On macOS, System Integrity Protection blocks changes to protected system locations even by the root account, unless it is disabled from the recovery environment.
Benefits, limits and common mistakes
The main benefit of mandatory control is damage containment: a vulnerability in one confined service gives an attacker only that service’s narrow permissions. It also supports privilege separation and process isolation, two neighboring defenses that it strengthens rather than replaces.
- Disabling it to fix problems: switching the policy off after a denial removes protection for every program, not only the broken one.
- Overly broad rules: a profile that allows writing everywhere looks enforced but confines nothing.
- Ignoring audit logs: running in permissive or complain mode first and reading the denials is the reliable way to build a working policy.
- Assuming kernel safety: a kernel exploit can bypass mandatory control entirely, because the policy is enforced by the kernel itself.
Mandatory access control is therefore one layer of OS hardening, combined with prompt security updates, memory protection and exploit mitigation, rather than a complete defense on its own.
The idea in brief
Think of an office building with rules set by the security department. You may own your desk drawer, but you cannot give a visitor a key to the server room. Only the security department can change who goes where.
Mandatory access control works the same way inside a computer. Each program gets only the access its role needs. If one program is broken into, the damage stays inside its own small area.
A practical scenario
A university research group runs a Linux workstation that hosts a small internal web application for sharing experiment results. The web server runs under SELinux in enforcing mode, which confines it to its own content directory, its log files and the network port it serves.
Months later, a flaw in an outdated plug-in lets an attacker run commands through the web server process. The attacker tries to read researchers’ home directories, open an outgoing connection and install a persistent task. SELinux denies every one of these actions, because the web server’s type has no rules allowing them, and each denial appears in the audit log.
The administrator notices the burst of denials the next morning, patches the plug-in and restores the content directory from backup. The outcome is a contained incident: the attacker never left the web server’s narrow domain, and no research data was exposed.