DAC vs MAC: Discretionary vs Mandatory Access Control

When the owner of a file, bucket or document decides who else can read it, one careless share or one compromised owner account is enough to move data anywhere, and nothing in the system will stop it. Discretionary access control (DAC) leaves that decision to the owner; mandatory access control (MAC) moves it to a central policy that owners and even administrators cannot override at will. This guide compares the two models by threat model, how each works, where each fails and how to choose, with SELinux and AppArmor, classified environments and cloud guardrails as the worked examples. It is for security architects, platform engineers and identity teams deciding where owner discretion is acceptable and where it must be capped. For the Linux kernel mechanics of MAC in depth, see the Reference Monitors and Mandatory Access Control Guide; for the formal models behind it, see the Classic Security Models Guide.

Key takeaways

The short answer is who holds the pen. Under DAC the object's owner sets access and can pass it on; under MAC a central authority sets the rules and subjects cannot change them, grant them onwards or relabel data.
DAC cannot stop a compromised owner. Any program running as the owner inherits the owner's discretion, which is why malware and stolen sessions spread data so easily on DAC-only systems.
MAC is layered on top, not instead. Linux checks MAC after DAC, Windows checks integrity levels before the DACL, and cloud guardrails cap identity policies; in each case both must allow the action.
Classified environments are where MAC began, not where it ends. Labels and clearances defined the model, but today it mostly appears as program confinement, mobile sandboxes and organisation-wide cloud guardrails.
Use MAC where a mistake is unrecoverable. Put mandatory caps on internet-facing services, container hosts, regulated data and cloud organisations; leave everyday collaboration to discretionary sharing with monitoring.

The short answer

NIST SP 800-192 puts the difference simply: DAC "leaves a certain amount of access control to the discretion of the object's owner", while under MAC "access control policy decisions are made by a central authority, not by the individual owner of an object." NIST SP 800-53 Rev. 5 turns that into two control enhancements. AC-3(4) Discretionary Access Control describes a policy where a subject granted access can pass the information on, grant its privileges, change security attributes, choose attributes for new objects or change the access rules. AC-3(3) Mandatory Access Control describes a policy, uniformly enforced, where a subject is constrained from doing each of those things, with exceptions only for organisation-defined trusted subjects. The glossary adds that MAC is a type of nondiscretionary access control, the family that also includes role-based access control.

Side-by-side comparison

Dimension	DAC	MAC
Who sets access	The object owner, or anyone the owner authorises	A central security authority through system policy
Can a user pass access on?	Yes: copy, share or grant	No: constrained by AC-3(3)
Basis of decision	Identity of the requester against the object's permission list	Labels or types on subjects and objects compared by policy rules
Typical mechanisms	Unix owner, group and other bits; POSIX ACLs; Windows DACLs; file and folder sharing	SELinux, AppArmor, Smack; Windows Mandatory Integrity Control; Android SELinux; multilevel secure systems
Effect of a compromised account	Attacker gains everything the owner could do, including sharing	Attacker stays inside the label or domain the policy assigns
Administrator power	Root or Administrator bypasses most checks	Policy binds privileged processes too, unless they are trusted subjects
Change rate	High: users change sharing daily	Low: policy changes go through the security authority
Main cost	Permission sprawl and weak accountability	Policy engineering, label management and denial troubleshooting
800-53 enhancement	AC-3(4)	AC-3(3)

Threat model: what each defends against

ATT&CK references below are from ATT&CK v20.

Threat	DAC alone	With MAC
Malware running as the user reads and exfiltrates the user's files	Allowed: the process acts with the owner's rights	Limited where the program is confined to its own types or paths
Exploited web service, T1068 Exploitation for Privilege Escalation	Gains the service account's rights and anything world-readable	Confined domain blocks access outside its declared files, ports and capabilities, even as root
Permission tampering, T1222.002 Linux and Mac Permissions	Owner or root can widen permissions at will	Label and policy unchanged by chmod; relabelling is itself policy-controlled
Abuse of setuid binaries, T1548.001 Setuid and Setgid	Elevated process passes DAC checks	Elevated process is still held to its domain
Container breakout, T1611 Escape to Host	Root in container may reach host files if other isolation fails	Container process type or profile denies host file access
Insider oversharing a sensitive document	Allowed: sharing is the owner's discretion	Label-enforced encryption or classification rules restrict recipients

The pattern is that DAC answers "is this person allowed?", while MAC also answers "is this program, acting for anyone, allowed to do this with data of this kind?". The second question is what contains exploitation and malware.

How DAC works and where it fails

On Unix-like systems every file has an owner, a group and permission bits for owner, group and others, optionally extended with POSIX ACLs; the owner, or root, can change them with chmod, chown and setfacl. On Windows every securable object carries a discretionary access control list (DACL) whose entries the owner can edit. Collaboration platforms and cloud storage follow the same model: the creator shares a file, folder or bucket and can grant onward rights. Details of Linux permissions, setuid and ACL masks are in the Linux File Permissions, SUID and ACLs Guide.

The Trojan horse problem: any program the owner runs can exercise the owner's discretion, so a malicious or exploited program can copy data or loosen permissions without the owner knowing.
Superuser bypass: root and local administrators override DAC, so one privileged compromise defeats every owner's choices.
Sprawl and drift: permissions accumulate through quick fixes such as world-writable directories and "anyone with the link" shares, and nobody owns the cleanup.
No information flow control: a reader of a sensitive file can write its contents into a public one, because DAC governs objects, not the data that moves between them.

How MAC works

Linux: SELinux and AppArmor

The Linux kernel documentation describes the Linux Security Module (LSM) framework as hooks for security checks, and names SELinux, Smack, TOMOYO and AppArmor as the primary MAC users. Active modules are listed in /sys/kernel/security/lsm. Red Hat's SELinux documentation states that "SELinux policy rules are checked after DAC rules", so if DAC denies first no SELinux denial is logged; a request must pass both. SELinux labels every process and object with a context of user, role, type and security level, and policy rules decide which types may interact; enforcing is the default and recommended mode, permissive logs without blocking, and denials appear as type=AVC records in /var/log/audit/audit.log. AppArmor, installed and loaded by default on Ubuntu, instead attaches per-program profiles in /etc/apparmor.d/ using path-based file rules and capability rules, in enforce or complain mode. See the SELinux Guide and the AppArmor Guide.

Windows: Mandatory Integrity Control

Microsoft documents four integrity levels (low, medium, high and system). Standard users run at medium, elevated users at high and services at system. Mandatory Integrity Control is evaluated before the DACL check, so a low-integrity process cannot write to a medium-integrity object even if the DACL allows it; objects are created with a no-write-up policy by default and unlabelled objects are treated as medium. It is a narrow MAC (integrity, not confidentiality) but shows the same layering: the mandatory check caps the discretionary one.

Android

Android's documentation states that SELinux applies MAC over all processes, including those running with root privileges, and that from Android 5.0 SELinux is fully enforced across all domains. Before that, app sandboxes relied on a unique Linux user ID per app, a DAC boundary. Android is the largest real-world demonstration that MAC can run in enforcing mode at consumer scale when the platform owner writes the policy.

Classified environments: the origin of MAC

NIST's glossary gives the classic example: in military security "an individual data owner does not decide who has a top-secret clearance, nor can the owner change the classification of an object from top-secret to secret." NIST SP 800-44 frames MAC as restricting access by the sensitivity of a resource, represented by a label, against the formal clearance of the user. Multilevel security systems implement this with sensitivity levels and categories (compartments) on every subject and object, enforcing the Bell-LaPadula rules that a subject may not read above its clearance or write below it, so data cannot leak downwards. SELinux's MLS policy is one implementation of this on Linux.

Government classification schemes define the labels, not the technology. The UK Government Security Classifications Policy, for example, uses OFFICIAL, SECRET and TOP SECRET tiers (the policy page was last revised in August 2024 when checked in November 2026). Most commercial organisations never deploy label-based multilevel MAC, but the idea carries over: a data classification scheme becomes mandatory when systems, not owners, enforce what each label allows. See the Data Classification Guide and Security Clearances for Cyber Security Jobs.

How modern clouds blend DAC and MAC

Cloud platforms rarely use the words, but their policy layering is the DAC and MAC split. Account owners and resource owners grant access through identity and resource policies (discretionary), while an organisation-level layer sets a ceiling those owners cannot raise (mandatory). Platforms are listed alphabetically.

Platform	Discretionary layer	Mandatory layer	Behaviour per vendor docs
AWS	IAM identity policies and resource policies in each account	Service control policies (SCPs) in AWS Organizations	SCPs set the maximum available permissions and grant none; they restrict users and roles in member accounts including the root user; the management account is not affected
Microsoft Purview	User sharing and "let users assign permissions" labels	Sensitivity labels where the admin assigns permissions	Encrypted content stays encrypted wherever it goes, and changing the encryption needs Export or Full Control rights, the Rights Management issuer or owner role, or super user status

Other cloud platforms provide comparable organisation-level policy layers; for one example, see the Google Cloud Organization Policy Guide. Two caveats keep the analogy honest. First, guardrails cap permissions but do not label data and track its flow, so they are mandatory ceilings rather than full MAC. Second, they have trusted subjects: AWS documents that SCPs do not restrict the management account or service-linked roles, and Purview super users can always read encrypted content. Those exceptions are exactly what AC-3(3) means by organisation-defined trusted subjects, and they need the strongest controls in the estate. See the AWS Organizations and SCPs Guide.

Where identity fits

Non-human identities are where DAC hurts most. A service account or workload role with owner rights over its data can be used by anyone who steals its key, and it never questions a request. MAC-style caps limit the damage: an SELinux domain confines what a daemon's process can touch whatever its Unix user, and an organisation guardrail limits what any role in an account can do whatever its attached policy says. Pair those caps with least-privilege grants for each machine identity, as described in the Least Privilege Techniques Guide.

Decision criteria

Situation	Lean towards	Why
Team collaboration on everyday documents	DAC with monitoring and expiry on external shares	Owners know who needs access; MAC friction outweighs risk
Internet-facing Linux services and container hosts	MAC in enforcing mode on top of DAC	Contains exploitation even when the process runs as root
Regulated or classified data	Label-based mandatory controls	Owners must not be able to downgrade or reshare
Multi-account cloud organisations	Discretionary account policies under mandatory guardrails	Account teams move fast inside a ceiling they cannot raise
Job-function access across many users	RBAC, a nondiscretionary model	Roles administered centrally scale better than owner grants; see the Authorisation Models Guide

Small organisations: keep the distribution's default MAC (SELinux or AppArmor) enforcing rather than disabling it, set a short list of organisation guardrails and use DAC for the rest. Large organisations: treat MAC policy as code with owners, reviews and tests, map data classification labels to enforced controls, and inventory every trusted subject that sits outside the mandatory layer.

Worked scenario

A software company runs a customer portal on Linux hosts and stores exports in cloud storage. A developer set the export directory to world-writable during an incident and never reverted it, and the portal's role can write to any bucket in the account. An attacker exploits a file upload flaw and gets code execution as the web service user. Under DAC alone the attacker can write a web shell into the world-writable directory and use the role to copy exports to a bucket they control. With SELinux enforcing, the web server's domain can write only to paths labelled for it, so the web shell write is denied and logged as an AVC record even though the Unix permissions allow it. With an organisation guardrail denying storage writes outside approved accounts, the copy fails even though the role's own policy allows it. The fixes that follow are discretionary hygiene (revert the directory permissions, narrow the role) backed by mandatory caps that held when hygiene failed.

How to implement mandatory controls without outages

Inventory where DAC is the only control: list hosts with MAC disabled or permissive, cloud accounts outside guardrails and data stores where owners can share externally.
Start in a learning mode: SELinux permissive, AppArmor complain or a guardrail tested on a sandbox organisational unit. AWS recommends testing SCPs before attaching them to the root and moving accounts in gradually.
Read the denials: review AVC and AppArmor logs or policy simulation output for at least one full release cycle, and fix labels or profiles rather than adding broad allow rules.
Enforce in rings: internet-facing and container hosts first, then internal servers; one organisational unit at a time for guardrails.
Define trusted subjects explicitly: list the accounts, roles and processes outside the mandatory layer and give them extra monitoring and approval.
Roll back narrowly: switch a single SELinux domain to permissive or one AppArmor profile to complain, or detach a guardrail from one unit, rather than disabling the layer.

Detection and measurement

Log every switch to permissive or complain, every policy load, every relabel and every guardrail change, and alert on them; an attacker with root will try to turn MAC off before doing anything noisy. Monitor external sharing events on discretionary platforms.

MAC coverage: percentage of Linux hosts with SELinux or AppArmor enforcing; target 100% for internet-facing and container hosts.
Unconfined services: count of network-facing processes running unconfined or in a permissive domain.
Guardrail coverage: percentage of cloud accounts under organisation guardrails, excluding documented trusted accounts.
Trusted subject count: number of identities outside the mandatory layer, trended down.
Discretionary exposure: count of world-writable paths and public or "anyone with the link" shares on sensitive stores.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev 5	AC-3(4) Discretionary Access Control	Defines owner-controlled policy
NIST SP 800-53 Rev 5	AC-3(3) Mandatory Access Control	Defines uniformly enforced, non-delegable policy
NIST SP 800-53 Rev 5	AC-3(7) Role-based Access Control, AC-3(13) Attribute-based Access Control	Other nondiscretionary models often combined with MAC
NIST SP 800-53 Rev 5	AC-16 Security and Privacy Attributes, AC-4 Information Flow Enforcement	Labels and flow control that label-based MAC relies on
NIST SP 800-53 Rev 5	AC-25 Reference Monitor	The enforcement mechanism behind kernel MAC
NIST CSF 2.0	PR.AA-05	Access permissions defined in policy, enforced and reviewed with least privilege

Common failure patterns

Disabling SELinux to fix an outage: Red Hat strongly discourages disabled mode; fix the label or use a targeted permissive domain instead.
Running MAC in permissive or complain mode for good: logs pile up, nothing is blocked and dashboards still show the module as "installed".
Treating guardrails as complete MAC: ceilings limit actions but do not stop an owner sharing data inside what is allowed.
Unmanaged trusted subjects: management accounts, super users and unconfined administrative processes sit outside the mandatory layer and are rarely monitored as such.
Classification without enforcement: labels on documents that no system acts on are DAC with extra steps.

Practitioner checklist

Every Linux host runs SELinux or AppArmor in enforcing mode, with exceptions documented per domain or profile.
Switches to permissive or complain, policy loads and relabels generate alerts.
Internet-facing services and container runtimes run confined, never unconfined.
Cloud accounts sit under organisation guardrails, tested on a sandbox unit before wider attachment.
Trusted subjects outside the mandatory layer are listed, approved and monitored.
Sensitive data classes map to enforced controls such as admin-assigned encryption labels, not owner choice.
World-writable paths and public shares on sensitive stores are reported and removed.
Service accounts and workload roles have least-privilege grants beneath the mandatory caps.

DAC vs MAC: Who Decides Access and How Modern Systems Combine Them