Home / 13 · Access Control
13 — Access Control
Access Control Models
Who can do what to which resource — and on what basis is that decision made?
| Model | Decision Basis | Strength | Weakness |
|---|
DAC
Discretionary | Owner decides; ACLs per resource | Flexible; intuitive ownership | Leaks via Trojans; malware inherits rights; hard global audit |
MAC
Mandatory | System labels (Top Secret/Secret/...) on subjects + objects. Bell–LaPadula. | Strong central policy; Trojan-resistant | Rigid; admin-heavy; poor commercial fit |
RBAC
Role-Based | Users → roles → permissions | Scales with org; matches jobs; easy audit | Role explosion; static context |
ABAC
Attribute-Based | Subject/object/action/environment attributes | Most expressive; dynamic | Policy complexity; harder "who has what" audit |
DAC — Discretionary Access Control (full description)
Definition: the owner of each resource decides who may access it, at their own discretion — typically by editing an Access Control List (ACL) or Unix-style permission bits attached to the object.
# Access matrix view — rows = subjects, columns = objects:
report.pdf grades.db
alice rw r # alice owns report.pdf, grants bob read
bob r —
# Unix realisation: -rw-r--r-- = owner rw, group r, other r
# Decision: allow iff an ACL entry (or ownership) grants (user, action).
Walkthrough: Alice creates report.pdf and clicks "Share → Bob can view". The OS appends (bob, read) to the file's ACL. When Bob opens it, the reference monitor finds the entry and permits. Alice may later revoke it — or Bob may copy the file and re-share it himself.
Strengths
Intuitive (matches human ownership), zero central admin, flexible delegation, perfect for collaboration (files, Google Docs, GitHub repos).
Weaknesses — the exam attack
Trojan-horse leakage: malware running as Alice inherits all of Alice's rights and silently re-shares her files. Permissions
propagate uncontrollably (Bob copies → Bob owns the copy → original policy dead). Global audit ("who can read X, transitively?") is undecidable in general (Harrison–Ruzzo–Ullman result).
Use when: cooperation matters more than confinement — personal files, team docs, commercial sharing. Never for military secrets.
MAC — Mandatory Access Control (full description)
Definition: the system (not any user) enforces access from security labels: every subject carries a clearance, every object a classification (e.g. Unclassified < Confidential < Secret < Top Secret, plus compartment sets like {NATO}). No user — not even the owner — can override the policy.
# Bell–LaPadula rules (confidentiality):
READ: allow iff clearance(s) ≥ classification(o) # no-read-up
WRITE: allow iff classification(o) ≥ clearance(s) # no-write-down (*-property)
# Effect: information flows UP the lattice only.
# Example: Alice cleared Secret reads Confidential ✓, reads Top Secret ✗;
# a Secret process writing to an Unclassified file ✗ (would leak down).
Walkthrough: a general (Top Secret, {NATO}) opens a (Secret, {NATO}) battle plan — read allowed (down-read). The same general cannot paste it into an Unclassified memo — write-down blocked even though they "own" the session. A Trojan inside the Secret process is equally caged: labels, not identity, decide.
Strengths
Central, uniform policy;
Trojan-resistant (malware can't relabel); provable information-flow guarantees; mandatory audit trail.
Weaknesses
Rigid (legitimate downgrades need a trusted declassifier); labelling
everything and clearing
everyone is admin-heavy; poor fit for commercial workflows where owners must share freely.
Use when: confidentiality outranks convenience — military, intelligence, safety-critical regulators. Real systems: SELinux enforcing mode, Trusted Solaris. Integrity twin: Biba (no-write-up / no-read-down) + Clark-Wilson (well-formed transactions, separation of duties).
RBAC — Role-Based Access Control (full description)
Definition: permissions attach to roles (job functions), users are assigned to roles, and sessions activate a subset. Decision chain: user → role → permission. Role hierarchies let senior roles inherit junior permissions (Doctor inherits Nurse's read rights, plus prescribe).
# Hospital example:
roles: Nurse {read charts} Doctor {+ prescribe} Admin {+ admit/discharge}
users: alice → Nurse; bob → Doctor (inherits Nurse perms)
session(bob, night-shift) activates {Doctor} → prescribe(chart_7) PERMIT
session(alice, ...) prescribe(chart_7) → DENY (role lacks it)
Walkthrough: Bob is hired as Doctor → admin assigns role once → Bob instantly gains hundreds of mapped permissions. Bob moves to Admin → one role swap, no per-file edits. Auditing is a matrix lookup: "list everyone with prescribe" = members of Doctor+.
Strengths
Scales with headcount (onboard = assign role); mirrors org charts; least-privilege via sessions; easy, exact audits; separation-of-duties constraints (same user can't hold Cashier + Auditor).
Weaknesses
Role explosion: fine-grained needs ("night-shift cardiologists in Ward 3") spawn thousands of roles. Static — no time/location/device context without bolting on attributes (which is just ABAC). Role engineering (discovering the right roles) is expensive up front.
Use when: stable organisations with clear job functions — hospitals, banks, universities, enterprises. NIST RBAC standard (INCITS 359) with core / hierarchical / constrained / symmetric variants.
ABAC — Attribute-Based Access Control (full description)
Definition: access is computed at request time from a policy over attributes of the subject, the object, the action, and the environment — not from fixed roles or labels. The most expressive of the four models (full page → 14 · ABAC).
# Same hospital rule, now context-aware:
PERMIT iff subject.role == "doctor" AND subject.dept == object.dept
AND object.type == "medical_record" AND action == "read"
AND environment.time ∈ 07:00–19:00 AND environment.day ∈ Mon..Fri
Walkthrough: Dr. Bob (Cardiology) opens a Cardiology record at 10:00 Tuesday → all clauses true → PERMIT. Same Bob at 23:00, or opening an Oncology record, or from an unmanaged home laptop → DENY — with zero role changes, because attributes are re-read every request via the PIP.
Strengths
Fine-grained, dynamic, context-aware (time/location/device), composable with Boolean logic, no role explosion, single policy covers thousands of cases.
Weaknesses
Policy authoring/testing is hard; answering "who can access what?" needs simulation, not a lookup; attribute pipelines (HR feed, device posture) must be fresh and trustworthy or decisions rot.
Use when: fine-grained, context-dependent access at scale — cloud IAM, healthcare, zero-trust networks. Standards: XACML (PEP/PDP/PIP/PAP), OPA/Rego, AWS IAM, Cedar.
Theory — the classic policies behind MAC
Bell–LaPadula (confidentiality, military)
no-read-up: subject s may read object o iff clearance(s) ≥ classification(o)
no-write-down: s may write o iff classification(o) ≥ clearance(s)
# Info flows UP only — Secret can't leak to Unclassified.
Biba (integrity — the mirror) + Clark-Wilson
Biba no-write-up / no-read-down: low-integrity data can't taint high-integrity objects.
Clark-Wilson: commercial integrity via well-formed transactions + separation of duties.
Lattice: labels form a partial order (Unclassified < Secret < Top Secret); compartments add sets (e.g. {NATO, Crypto}) compared by ⊆.
Evolution
DAC → MAC → RBAC → ABAC
↑ ↑ ↑ ↑
owner state role attributes
based labels based + environment
Decision logic
# DAC
if (owner_of(resource).grants(user, action)) PERMIT
# MAC
if (clearance(user) ≥ classification(resource)) PERMIT
# RBAC (with hierarchy: senior roles inherit junior perms)
if (role(user) ∈ permitted_roles(resource, action)) PERMIT
# ABAC (next page in full)
if (policy(subject_attrs, object_attrs, env_attrs, action)) PERMIT
Order of evolution
Each model adds expressiveness. RBAC is a special case of ABAC where the only attribute is "role".
Exam one-liner: DAC=owner says, MAC=labels say (BLP up-only), RBAC=role says, ABAC=attributes say.