Can a resource owner always override a mandatory denial?

No. That is the core distinction from discretionary sharing authority.

Is MAC limited to military classifications?

No. Type-based application confinement is another important use.

Does MAC replace ordinary file permissions?

Not necessarily. Implementations such as SELinux can work alongside discretionary controls.

AI Glossary / Data governance and quality / Intermediate

Mandatory access control

Definition

Mandatory access control, or MAC, is an access-control approach in which a system enforces security policy that ordinary users or resource owners cannot override at their own discretion. Decisions may depend on security labels, process types, clearances, or other policy-defined attributes, depending on the model. The important distinction is the authority of the enforced policy. MAC does not mean merely that a rule is compulsory in an employee handbook.

What it means

A file owner may be allowed to share a file through ordinary permissions, yet a mandatory policy can still prohibit a particular process or user from accessing it. The owner's discretionary grant is not enough to bypass that policy. MAC is often associated with classified-information systems, but implementations also use it to confine applications. Different models protect different objectives, so one historical label hierarchy should not be presented as the definition of all mandatory access control.

How it works

Define the subjects, objects, operations, and security policy. Assign and maintain the labels or attributes the implementation uses, then enforce decisions at the relevant system boundary. Protect policy administration and test both intended access and prohibited actions. Where discretionary permissions also apply, understand how the two mechanisms interact. Investigate denied operations against the intended workflow instead of automatically weakening enforcement. Review policy changes, exceptions, and the status of enforcement because a configured policy provides little protection if it is not actually applied.

Three practical examples

Application confinement: a web-serving process is permitted to read its approved content but denied unrelated private files under an enforced policy.
Labeled information: a system applies centrally governed rules to transfers or access involving different information labels.
AI infrastructure: an inference process is confined to the model files and runtime resources required for its role, while access to unrelated training archives is restricted.

Think of it this way

Think of a building rule that an individual room occupant cannot override simply by lending a key. The building's controlled access system still applies the required restriction. The analogy is limited because MAC can govern processes and operations as well as people, and its policy may involve types, categories, and relationships rather than a simple ranking of rooms.

Worked example

In an original conceptual example, a report file has ordinary permissions that would allow a service account to read it. The mandatory policy permits the reporting process to read that file type but does not permit the web process to do so. The same account's involvement does not automatically make both operations equivalent: the process context matters in this hypothetical type-based design. An administrator who wants to support a new legitimate workflow must review the policy and labeling through the approved change process. Simply making the file broadly readable does not necessarily resolve the mandatory denial, and disabling enforcement would change the protection rather than explain the requirement.

Illustrative case study

Fictional example: Maple Models moves an inference artifact to a new directory and the service can no longer read it. The team investigates and finds that the resource's policy context no longer matches the approved deployment design. It corrects the configuration using supported procedures and tests the intended access. This invented case shows why a denial should prompt diagnosis of the policy and workflow rather than an immediate decision to switch off the control.

Common misconceptions and mistakes

Do not confuse MAC with a message authentication code or a network interface's MAC address. Do not assume every MAC system uses the same clearance hierarchy or Bell-LaPadula rules. Avoid claiming that MAC makes compromise impossible: implementation flaws, incorrect policies, and privileged administration still matter. Also, an application's legitimate permissions may still allow harmful actions within its authorized scope. Mandatory enforcement limits defined operations; it does not replace secure software, monitoring, or careful data design.

Business use

MAC can limit the reach of compromised or misbehaving applications and enforce rules that resource owners should not be able to bypass. For AI services, it may help separate inference, training, and administrative resources when implemented appropriately. Assess the operational cost of policy management and provide a supported path for legitimate changes. Keep administrators accountable and document the intended confinement. The business benefit comes from a maintained, enforced policy that matches the service, not merely from enabling a security feature by name.

Check your understanding

A file is made readable through ordinary permissions, but an enforced mandatory policy denies the requesting process. Is the ordinary grant necessarily sufficient?

Answer: No. The request must satisfy the relevant mandatory policy as implemented. Diagnose the policy context and intended access rather than assuming one permission setting controls everything.

Related terms

Discretionary access control
Least privilege
type enforcement
security label
SELinux
application confinement
reference monitor

Learn next

compare who can change permissions in discretionary and mandatory arrangements. Use a harmless test environment to inspect a documented confinement policy and its expected allowed operations. Separate policy design, labeling, enforcement status, and ordinary permissions when explaining an access decision.

Sources

Sources: NIST CSRC, mandatory access control, https://csrc.nist.gov/glossary/term/mandatory_access_control , glossary material consulted; SELinux Project, Mandatory Access Control, https://github.com/SELinuxProject/selinux-notebook/blob/main/src/mac.md , project documentation excerpt consulted; Red Hat, How SELinux improves Red Hat Enterprise Linux security, https://developers.redhat.com/articles/2023/09/21/how-selinux-improves-red-hat-enterprise-linux-security , relevant vendor excerpt consulted. Examples are conceptual and original. No policy was deployed, and exact platform rules require implementation-specific documentation.

Previous: Manager agent Next: Manhattan distance