Mandatory Access Control (MAC): the system decides, not you

When discretion is the risk

The previous article ended on DAC’s original sin: the owner decides, so information flows wherever an owner — or a program running with the owner’s rights — sends it. A trojan horse leaks a classified file and DAC sees nothing wrong, because the access was authorized. For most business data that is an acceptable trade for convenience. But some information must not flow, no matter who wants to send it, and for that you need a model where discretion itself is removed. That model is Mandatory Access Control (MAC).

MAC flips DAC’s defining question. DAC asks “what does the owner want?” MAC asks “what does the classification allow?” — and the owner’s wishes are simply not part of the answer. A general who owns a Top Secret document cannot email it to an uncleared clerk, not because they lack permission to send email, but because the system forbids that information flow and no one below the security officer can override the rule. Access is decided by a central, system-wide policy based on labels, and it is mandatory because it is imposed, not chosen.

This is the model born in defense and intelligence, formalized in the same 1985 Orange Book that named DAC. But do not file it under “military only” — as we will see, MAC quietly runs on your phone, your Linux servers, and your Windows browser sandbox. The ideas are 50 years old and more relevant than ever.

Labels: clearances and classifications

MAC’s machinery starts with labels. Every subject (a user, or a process acting for them) carries a clearance. Every object (a file, a message, a record) carries a classification. The system compares the two on every access. In the classic government scheme the labels have two parts.

A hierarchical level — the familiar ladder: Unclassified, then Confidential, then Secret, then Top Secret, each strictly more sensitive than the last. A set of non-hierarchical compartments (also called categories) — things like NUCLEAR, CRYPTO, HR, FINANCE — that encode need to know. A label is the pair: (level, set of compartments), for example (Secret, {CRYPTO, NUCLEAR}).

Access requires that the subject’s label dominates the object’s: the subject’s level is at least as high, and the subject’s compartment set includes all of the object’s. Someone cleared (Top Secret, {CRYPTO}) cannot read a (Secret, {NUCLEAR}) document — their level is high enough, but they lack the NUCLEAR compartment. This is a lattice: labels form a partial order where some pairs are simply incomparable, and that structure is what lets MAC enforce need-to-know on top of classification level. It is far more precise than a single ladder.

One subtlety trips up newcomers: a subject’s clearance (the maximum they are trusted with) is not the same as the level they are currently operating at. A Top Secret analyst may log in a Secret session to work on Secret material; while there, the write-down rules treat them as a Secret subject. Systems that let a subject run at their maximum and quietly track the highest thing they have touched use a high-water-mark approach, which raises the effective level as they read up — a design that is simple but tends to over-classify everything downstream. The distinction between “cleared for” and “running at” is small but essential to reasoning about the flow rules that follow.

Bell-LaPadula: no read up, no write down

Labels tell you who is trusted with what, but the genius of MAC is in the flow rules that use them. The foundational model is Bell-LaPadula (BLP), built in the 1970s to protect confidentiality. It has two deceptively simple rules.

No read up (the simple security property). A subject may not read an object whose classification is above its clearance. A Confidential user cannot open a Secret file. This is the obvious rule — it is why you need clearance at all.

No write down (the star property, written *-property). A subject may not write to an object whose classification is below its clearance. A Top Secret process cannot write into an Unclassified file. This is the non-obvious rule, and it is the whole point: it stops classified information from flowing downward to those not cleared for it.

Sit with the second rule, because it is what closes the gap DAC left open. Recall the trojan horse: Daniel tricks Sara into running a program that reads a sensitive file and copies it somewhere Daniel can reach. Under BLP, Sara’s process runs at the sensitive level, so it cannot write down to any location Daniel (at a lower level) can read. The leak is blocked by the system, regardless of what Sara’s program tries to do or what any owner permitted. MAC controls information flow, not just access — and that is the capability DAC fundamentally lacks. Summarized as a slogan: read down, write up is allowed; read up and write down are not.

Two refinements make BLP workable in reality. The tranquility principle says labels should not change during use — “strong tranquility” forbids it outright, “weak tranquility” allows changes that do not violate the rules — because a label that shifts mid-operation can silently open a leak. And because pure no-write-down would make it impossible to ever declassify or summarize anything, real systems designate a few trusted subjects: carefully vetted processes or officers permitted to move information downward under controlled review. Those trusted subjects are the deliberate, audited exceptions that keep a rigid model usable — and the fact that they must be designated and trusted is itself a reminder of how seriously MAC takes downward flow.

---
config:
  flowchart:
    rankSpacing: 80
    nodeSpacing: 55
---
flowchart TD
  accTitle: Bell-LaPadula no-read-up and no-write-down rules
  accDescr: A subject cleared at the Secret level branches to its four possible operations. Writing to a Top Secret object (write up) is allowed. Reading a Top Secret object (read up) is denied. Reading an Unclassified object (read down) is allowed. Writing to an Unclassified object (write down) is denied. Allowed operations are drawn with solid arrows and denied operations with dotted arrows. The net effect is that information can only ever flow upward, toward higher classification.
  SUBJ["Subject cleared: Secret"]
  SUBJ --> WU["Top Secret object<br/>write up: ALLOWED"]
  SUBJ -.-> RU["Top Secret object<br/>read up: DENIED"]
  SUBJ --> RD["Unclassified object<br/>read down: ALLOWED"]
  SUBJ -.-> WD["Unclassified object<br/>write down: DENIED"]

Biba: the integrity mirror

Bell-LaPadula protects secrecy — keeping data from leaking down. But sometimes you care about the opposite: keeping low-quality data from corrupting high-integrity data. That is integrity, and the Biba model is Bell-LaPadula turned upside down. Its rules mirror BLP exactly: no read down (don’t read data less trustworthy than you, lest it corrupt your reasoning) and no write up (don’t write into data more trustworthy than you). Where BLP makes information flow up toward secrecy, Biba makes it flow down toward less-trusted zones, so trusted data stays uncontaminated.

Biba is not a museum piece: it is essentially how Windows Mandatory Integrity Control works, and the intuition behind why a low-integrity process (say, a sandboxed browser tab) cannot write into high-integrity system locations. Confidentiality and integrity are dual concerns, and MAC has a model for each. Real systems often want both at once, which gets complicated fast — one reason pure multilevel security is rare outside defense, while targeted MAC (below) is everywhere.

Beyond secrecy: Clark-Wilson and Chinese Wall

Bell-LaPadula and Biba are the famous pair, but the MAC family has models for concerns they do not capture. Clark-Wilson targets commercial integrity: instead of levels, it insists that data be changed only through well-formed transactions run by certified programs, and that duties be separated so no single actor can both create and approve a change. It is the formal ancestor of “you cannot approve your own expense report” — the separation of duties that RBAC will make practical two articles from now.

The Chinese Wall model (Brewer-Nash) captures conflict of interest, which is dynamic in a way levels are not. A consultant may access data from one bank in a market; the moment they do, the policy must forbid them from touching a competing bank’s data — access to one wall removes access to another, based on history. No static clearance expresses that. These models matter because they show MAC is not only about military secrecy: the same “system-imposed, non-discretionary policy” idea models financial integrity and conflict-of-interest, and those ideas resurface directly in policy-based and attribute-based control later in this module.

MAC in the real world #1: SELinux

The most widely deployed MAC system on Earth ships in every Android phone and most enterprise Linux servers: SELinux (Security-Enhanced Linux), originally developed by the NSA and now part of the mainline kernel. Crucially, SELinux is not primarily about military classification levels. Its workhorse is type enforcement: every process runs in a domain and every object has a type, and a central policy states exactly which domains may act on which types. A web server in the httpd_t domain can read files of type httpd_content_t and nothing else — even if the DAC permissions would allow more.

That “even if DAC would allow more” is the essence of MAC. If an attacker compromises the web server and it tries to read /etc/shadow, the Linux permissions might be tricked, but SELinux’s policy never granted httpd_t access to shadow_t, so the kernel denies it. The owner cannot chmod their way around it; the policy is mandatory. This is why SELinux is such a powerful containment tool: it confines a compromised process to exactly what its role legitimately needs, embodying Zero Trust’s “assume breach” at the OS level.

Contexts and modes

Every labeled thing in SELinux carries a context, shown as user:role:type:level, e.g. system_u:object_r:httpd_content_t:s0. Run ls -Z or ps -Z and you see them. Notice that context has four fields: SELinux actually bundles three access-control models at once — type enforcement (the everyday workhorse), an RBAC layer that constrains which types a role may reach, and an optional MLS layer (the s0 level) for Bell-LaPadula-style multilevel deployments. Most systems use type enforcement and leave MLS off, which is why “SELinux equals military classification” is a common but wrong assumption.

SELinux runs in one of three modes: enforcing (deny and log), permissive (allow but log what would have been denied — invaluable for developing policy), and disabled (off entirely). The permissive mode is the honest way to debug a policy without losing protection permanently, and the discipline is to develop in permissive, then return to enforcing — never to ship with it disabled.

MAC in the real world #2: everywhere else

Once you know the shape, MAC appears throughout modern computing. AppArmor (default on Ubuntu and SUSE) is a path-based MAC that confines programs to declared file paths and capabilities — simpler than SELinux, same mandatory principle. Windows Mandatory Integrity Control tags processes with integrity levels (Low, Medium, High, System) and forbids low-integrity code from writing to higher-integrity objects — Biba in production, and the reason a sandboxed browser or a downloaded file runs “Low” and cannot tamper with your system.

The app sandboxes on iOS and Android are MAC: each app is confined by a system policy to its own data and a declared set of entitlements, and no app — however much its developer might wish — can reach another app’s private storage. Containers and hypervisors lean on MAC (SELinux/AppArmor profiles) to keep a compromised container from escaping to the host. Even your browser’s site isolation is MAC-like: a mandatory, system-enforced boundary that the sites themselves cannot negotiate away. The label-and-enforce idea from 1970s defense research turns out to be the backbone of modern sandboxing.

What changed between the failed MLS mainframes and today’s ubiquitous sandboxes is who does the labeling. Classic MAC asked humans to classify data, which was slow and error-prone. Modern targeted MAC labels software components — this app, that service, this container — which a developer or distribution can define once and ship. The policy is still mandatory and unoverridable by the end user, but the labeling burden moved from “classify every document by hand” to “declare what each program may touch,” and that shift is exactly what let mandatory control escape the defense niche and become invisible, default infrastructure on billions of devices.

Multilevel security, guards, and the hard problem

Running genuinely different classification levels on one system — true Multilevel Security (MLS) — is one of the hardest problems in security, and the history is humbling. In the 1980s and 1990s, vendors built MLS operating systems and databases evaluated to the Orange Book’s stringent B1/A1 classes; almost all of them failed commercially. They were expensive, slow to certify, and painful to use, and the market for “one machine safely handling Secret and Unclassified at once” was smaller than hoped. The lesson shaped the field: full MLS is reserved for defense and intelligence, while the ideas were repackaged into the lighter, targeted MAC that actually ships today.

Where information genuinely must cross levels, defense systems use a cross-domain solution (CDS) or guard — a small, heavily assured component whose only job is to move data between a high and a low network under strict rules, inspecting and sanitizing every transfer. And to stop a subtle leak where the mere existence of a high-level record reveals classified information, MLS databases use polyinstantiation: two records can exist at the same key, one visible at each level, so a low-cleared user querying a “free” slot never learns that a high-cleared record secretly occupies it. These are exotic mechanisms, but they reveal how deep the “control the flow, not just the access” commitment goes when the stakes are national security.

Why MAC did not take over the world

If MAC is strictly stronger than DAC, why is your laptop’s primary model still discretionary? Because assurance without usability does not survive contact with real work. The rigidity that blocks the trojan horse also blocks the analyst who legitimately needs to move a chart from a classified deck into an unclassified briefing — and every such friction point is pressure to weaken, bypass, or disable the policy. History rewarded models that people would actually keep enabled. That is precisely why modern MAC went targeted: instead of classifying everything, SELinux and AppArmor confine a handful of high-risk services (web servers, containers) and leave the rest of the system on ordinary DAC. You get most of the containment benefit for a fraction of the labeling cost — a pragmatic compromise that made mandatory control finally deployable at scale.

Covert channels: the limit of labels

Even a perfectly enforced label policy has a residual weakness worth knowing: the covert channel. Bell-LaPadula stops a high process from writing down a file — but two colluding processes can still leak information through side effects the label rules do not govern. A high process can vary its CPU usage or fill a disk in a pattern a low process observes, signaling bits without ever “writing” anything classified. These timing and storage channels are slow and hard to exploit, but in the highest-assurance settings they must be analyzed and mitigated. The takeaway is humbling and useful: labels control the named information flows, not every physical one, so MAC raises the bar enormously without ever reaching a mathematical absolute.

Strengths and weaknesses, honestly

Strengths. MAC provides genuine information-flow control — the one thing DAC cannot do — so it resists the trojan horse and confused-deputy attacks structurally, not by vigilance. Its policy is central and consistent: the organization, not each owner, states the rules, so “no Secret data ever reaches an Unclassified channel” is enforceable as an invariant. It is tamper-resistant by design — ordinary users, including owners, cannot weaken it. And as a containment layer it is superb: a compromised process is boxed into exactly its labeled needs.

Weaknesses. That same rigidity is the cost. Everything must be labeled, correctly, and keeping labels accurate as data is created and transformed is genuinely hard. The central policy must anticipate every legitimate workflow, and when it does not, users hit walls with no discretionary escape hatch — which is why unmanaged MAC gets disabled. It is administratively heavy, a specialized skill. It tends toward over-classification (when in doubt, label it higher), which then stalls collaboration. And no MAC system fully eliminates covert channels — sneaky ways to signal information through timing or resource usage that bypass the label rules. MAC buys assurance and pays in flexibility and effort.

A worked example: the research folder, revisited

Return to Sara’s /research/roadmap folder from the DAC article, but now imagine the organization runs MAC with the roadmap classified Confidential and Daniel cleared only Internal. Sara can still set discretionary permissions — DAC is still there — but they no longer have the final say. When Daniel tries to open q3.pdf, the mandatory policy checks his clearance against the file’s classification, finds Internal does not dominate Confidential, and denies him regardless of any ACL Sara added. And when Daniel’s helpful trojan tries to copy the file to an Internal share, “no write down” blocks it: a Confidential process cannot write to an Internal object.

The very leak that DAC could not prevent is now structurally impossible — not because Sara was careful, but because the system’s policy makes that information flow illegal. That is the whole value proposition of MAC in one scenario. Notice, too, what it cost: someone had to classify the roadmap, clear Daniel, and maintain both labels. Nobody gets that assurance for free, which is why MAC is deployed where the stakes justify the overhead and complemented by lighter models everywhere else.

And notice what MAC still does not solve. It stopped the leak, but it said nothing about why Daniel should or should not see the roadmap in terms of his job. His clearance is about trust and sensitivity, not about the fact that he works in support and the roadmap belongs to product. Encoding “access follows what your job is” — cleanly, at the scale of thousands of employees — is a different problem from controlling information flow, and it is the one the next model was built for. MAC drew the hard line; RBAC will organize everything inside it.

Where MAC fits among the models

In the map from the DAC article, MAC is the answer to uncontrolled information flow. It sits as a mandatory floor beneath the more flexible models: DAC handles owner-driven sharing, RBAC (next article) handles job-based access at enterprise scale, ABAC handles context — and MAC, where present, overrides all of them with non-negotiable label rules. A request in a fully layered system must satisfy the MAC policy, the DAC permissions, the RBAC role check, and any ABAC rules; any layer can deny.

MAC is also the conceptual ancestor of ideas you will meet later. Its “central policy the owner cannot override” is the seed of policy-based access control and policy-as-code; its information-flow thinking underlies modern data-loss-prevention and data-classification programs. When a cloud provider tags data as “sensitive” and blocks it from leaving a region, that is MAC thinking applied to the cloud. The vocabulary changed; the idea — labels plus a mandatory, system-enforced flow policy — did not.

MAC’s modern descendants: DLP, data classification, and the cloud

You may never configure a Bell-LaPadula lattice, but you almost certainly work inside its descendants. Data classification programs — the “Public / Internal / Confidential / Restricted” tiers most enterprises now run — are MAC labels by another name, and the tooling that stamps a sensitivity label on a document and then refuses to let it be emailed externally is enforcing a no-write-down rule in spirit. Data Loss Prevention (DLP) is the commercial reincarnation of information-flow control: it inspects content, assigns or reads a classification, and blocks flows that would move sensitive data to an unauthorized channel — precisely the concern BLP formalized, applied to email, uploads, and USB drives instead of classified networks.

The cloud revived these ideas at scale. When you tag a storage bucket or a dataset as “sensitive” and a policy blocks it from leaving a region or being made public, that is mandatory, system-enforced, label-driven flow control — MAC thinking wearing cloud vocabulary. Microsoft Purview sensitivity labels, AWS resource tags wired into service control policies, and Google’s VPC Service Controls all express “this data may not flow there, no matter who asks,” which is the mandatory floor idea exactly. Even confidential computing — keeping data encrypted and isolated even from the host operator — is the label-and-enforce instinct pushed into hardware.

Seeing this lineage is practically useful: it means the 1970s theory is not trivia but the mental model behind controls you configure today. When a DLP rule frustrates you by blocking a legitimate send, you now know it is a no-write-down rule missing a trusted subject exception — and you know the right fix is a controlled, audited downgrade path, not disabling the rule. MAC’s vocabulary gives you the language to reason about modern data-protection controls that otherwise look like arbitrary corporate friction.

Recap

Mandatory Access Control is the model that removes discretion to gain assurance:

1. The system decides, not the owner. A central policy based on labels governs access; no ordinary user, not even an owner, can override it. That is what “mandatory” means.
2. Labels combine level and compartment. Clearances and classifications form a lattice of (level, compartments), enforcing both sensitivity and need-to-know; access requires the subject’s label to dominate the object’s.
3. Flow rules are the core. Bell-LaPadula (no read up, no write down) protects confidentiality and closes the trojan-horse gap; Biba mirrors it for integrity (no read down, no write up).
4. It runs everywhere, quietly. SELinux type enforcement, AppArmor, Windows Mandatory Integrity Control, and iOS/Android sandboxes are all MAC layered over discretionary permissions.
5. Assurance costs flexibility. Labeling, policy maintenance, and rigidity are real burdens — so MAC is a non-negotiable floor for high-stakes data, complemented by lighter models, not a universal replacement.

Three questions to test yourself

1. Explain, using the “no write down” rule specifically, why Bell-LaPadula stops the exact trojan-horse leak that DAC allows. What would have to be true about the attacker’s target level for the leak to succeed under BLP?
2. A teammate says “we use SELinux, so we’re doing multilevel military security.” Correct the misconception: what does SELinux’s type enforcement actually enforce, and how does that differ from Bell-LaPadula classification levels?
3. Your organization wants both to keep secrets from leaking and to keep untrusted input from corrupting critical data. Which model handles each concern, and why can enforcing both at once create conflicting label requirements for the same subject?

Hands-on exercises

1. Watch MAC deny something DAC allowed. On a SELinux system (a Fedora/RHEL VM or container), put SELinux in enforcing mode, then try to make a service read a file outside its allowed type (for example, move web content to a non-httpd_content_t path and reload). Observe the denial in the audit log even though the DAC permissions are correct, then use audit2allow to read what policy would be needed.
2. Find the integrity levels on your own machine. On Windows, use a tool like Process Explorer to view the integrity level of your browser and a system process, and confirm the browser runs lower. On mobile, read an app’s declared entitlements/permissions. Map what you find back to Biba’s “no write up.”
3. Design a two-level label scheme. For a small dataset you know (say, HR records vs. public announcements), define two classifications and two clearances, then write the Bell-LaPadula read/write rules for a subject at each level. Identify one legitimate workflow your rules would block, and describe the controlled exception a real MLS system would need to permit it.