Access control models: RBAC, DAC and MAC

Once a system knows who you are, it needs a consistent way to decide what you may access. Writing a separate permission for every person and every file does not scale: a company with a thousand employees and a million documents would drown. Access control models are the organising ideas that keep those decisions manageable. Three of them appear in every security textbook, in operating systems and in business software: discretionary access control (DAC), mandatory access control (MAC) and role-based access control (RBAC).

DAC: the owner decides

In discretionary access control, each resource has an owner, and the owner chooses who else may use it. NIST defines it as access control where the owner of an object can pass permissions on to other subjects at their discretion. You use DAC every day: when you share a document and pick who can view or edit it, or when files on your Mac carry read and write permissions for their owner, a group and everyone else.

DAC is flexible and easy to understand, which is why it is everywhere. Its weakness is the same flexibility. If an owner shares too widely, or if malicious software runs with the owner’s identity, it can use the owner’s permissions and grant access onward. The system trusts the owner’s judgement, and anything acting as the owner.

MAC: the system decides

Mandatory access control takes that discretion away. A central policy, set by administrators, labels both people and resources, for example with clearance levels like “confidential” and “secret”, and the system enforces the rules no matter what individual users want. NIST describes it as access control that restricts access based on the sensitivity of information and the formal authorisation of the subject, and that users cannot override.

MAC is common in military and government systems, and its ideas live on in modern operating systems. On macOS, System Integrity Protection and app sandboxing are mandatory in spirit: even an administrator cannot casually modify protected system files, and a sandboxed app cannot reach outside what its entitlements allow, whatever the user clicks. The strength of MAC is that a compromised account cannot simply give data away. The cost is rigidity: setting up and maintaining labels is demanding, and strict policies can get in the way of ordinary work.

RBAC: permissions follow the job

Role-based access control, formalised by NIST researchers in the 1990s, groups permissions into roles that match jobs: “nurse”, “accountant”, “help desk”. People are assigned roles, and roles carry permissions. When someone joins the finance team, they get the finance role; when they move on, the role is removed and every associated permission goes with it.

RBAC is the backbone of most business software and cloud platforms because it maps security to how organisations actually work. It also makes audits simpler: instead of reviewing thousands of individual permissions, you review what each role can do and who holds it. Its classic failure mode is “role explosion” and “permission creep”: roles multiply to cover every exception, and people collect roles over the years without losing old ones. Regular access reviews are the cure.

Beyond the classic three

Real systems mix models. Attribute-based access control (ABAC) adds context to the decision: not only who you are and what role you hold, but the time of day, the device you use, or the network you are on. That contextual thinking leads directly to zero trust, covered in the last lesson of this course.

The same ideas apply to network access. FireAI’s rules are a mix of models: you, the owner of the Mac, decide per app what it may reach (discretionary), while FireAI’s security modes apply a stricter policy on top, for example “Under attack” lets only apps with an explicit Allow rule connect, whatever they try (closer to mandatory). Profiles that change rules by Wi-Fi network add the context that ABAC is about.

Choosing well

• Use RBAC for people in organisations, and review role membership at least a few times a year.
• Keep DAC for collaboration, but set sensible defaults (private unless shared) and watch public or “anyone with the link” sharing.
• Rely on MAC-style protections for what must never change: system files, security settings, audit logs.
• Whatever the model, apply least privilege and remove access as soon as it is no longer needed.