This chapter covers the three primary access control models tested on the SY0-701 exam: Discretionary Access Control (DAC), Mandatory Access Control (MAC), and Role-Based Access Control (RBAC). Understanding these models is critical because they form the foundation of how permissions are managed in operating systems, databases, and enterprise environments. This content maps to Domain 1.0 (General Security Concepts), Objective 1.1. You will learn the mechanisms, use cases, and exam traps for each model.
Jump to a section
Imagine a hotel where each guest receives a key card that grants access only to their assigned room floor and the gym, but not the executive lounge or other guests' rooms. This is Discretionary Access Control (DAC) because the guest can decide to lend their card to a friend, allowing them into their room. Now consider a military base: each person has a security clearance (e.g., Top Secret, Secret), and every document is labeled with a classification. A person can only access documents at or below their clearance level, regardless of who wrote them. This is Mandatory Access Control (MAC) because the system enforces rules based on labels, and users cannot override them. Finally, think of a corporate office where employees are assigned roles like 'Manager', 'Accountant', or 'Intern'. Each role has predefined permissions: Managers can approve expenses, Accountants can edit ledgers, Interns can view reports. This is Role-Based Access Control (RBAC) — access is based on job function, not identity or discretion. The key mechanistic insight: DAC trusts the owner, MAC trusts the system, RBAC trusts the role. Each model addresses different threats: DAC against user error, MAC against data leakage, RBAC against privilege creep.
What Are Access Control Models?
Access control models define how subjects (users, processes) can access objects (files, printers, databases). The SY0-701 exam expects you to compare DAC, MAC, and RBAC in terms of flexibility, security, and administration overhead. Each model addresses a different threat: DAC protects against unauthorized access by trusting object owners; MAC protects against data leakage by enforcing system-wide policies; RBAC protects against privilege abuse by limiting permissions to job functions.
Discretionary Access Control (DAC)
DAC is the most common model in personal operating systems like Windows (NTFS permissions) and Linux (file permissions). In DAC, the owner of an object has full discretion over who can access it and with what privileges. For example, on Linux, the file owner can use chmod to set read/write/execute permissions for the owner, group, and others. The key characteristic: access rights can be propagated or transferred by the owner. This makes DAC flexible but vulnerable to social engineering and malware that inherits the user's permissions.
How DAC works mechanically: 1. A subject (user) creates an object (file). 2. The system assigns the subject as the object's owner. 3. The owner sets an Access Control List (ACL) or permission bits. 4. When another subject tries to access the object, the system checks the ACL against the subject's identity. 5. If the subject is not authorized, access is denied.
Key components: ACLs, owner SID/UID, permission bits (rwx).
Variants: POSIX permissions (Linux), NTFS permissions (Windows), NFS exports.
Attack vector: A user with DAC can accidentally grant access to unauthorized users. Malware running under a user's context can modify permissions to spread.
Defense: Use DAC only when users are trusted and objects are low-sensitivity. For sensitive data, use MAC or RBAC.
Mandatory Access Control (MAC)
MAC is used in high-security environments like government and military systems (e.g., SELinux, Trusted Solaris). The system enforces access based on security labels assigned to subjects and objects. Users cannot override these rules. The classic implementation is Bell-LaPadula, which focuses on confidentiality: "no read up, no write down." A subject with a clearance of Secret can read Secret and Unclassified objects but cannot read Top Secret objects (no read up). They can write to Secret objects but cannot write to Unclassified objects (no write down) if that would leak Secret data to a lower classification.
How MAC works mechanically: 1. All subjects receive a security clearance (e.g., Top Secret, Secret, Confidential, Unclassified). 2. All objects receive a security classification label. 3. The system compares the subject's clearance to the object's label using a lattice-based policy. 4. Access is granted only if the policy permits it; no user negotiation.
Key components: Security labels, clearance levels, lattice, Bell-LaPadula (confidentiality), Biba (integrity).
Variants: SELinux (Linux), Windows Mandatory Integrity Control (MIC), AppArmor.
Attack vector: MAC is resistant to user error but can be bypassed if labels are incorrectly assigned or if there is a covert channel.
Defense: MAC is ideal for preventing data leakage from trusted insiders. Use SELinux in targeted or enforcing mode.
Real command example (SELinux):
# Check SELinux mode
getenforce
# Set context for a file
chcon -t httpd_sys_content_t /var/www/html/index.html
# List file context
ls -ZRole-Based Access Control (RBAC)
RBAC is the most common enterprise model (e.g., Active Directory groups, AWS IAM roles). Access is based on the subject's role (e.g., "HR Manager", "Network Admin"). Permissions are not assigned to individuals but to roles, and users are assigned to roles. This simplifies administration: when a user changes jobs, their role assignment changes, not their individual permissions.
How RBAC works mechanically: 1. Roles are defined based on job functions. 2. Permissions are assigned to roles (e.g., "HR Manager" can read employee records). 3. Users are assigned to one or more roles. 4. When a user requests access, the system checks the roles assigned to the user and the permissions of those roles.
Key components: Roles, permissions, user-role assignment, role-permission assignment, session.
Variants: NIST RBAC model (core, hierarchical, constrained), ABAC (Attribute-Based Access Control) which extends RBAC with attributes.
Attack vector: Role explosion (too many roles), role creep (users accumulate permissions over time), privilege escalation if roles are poorly defined.
Defense: Implement role mining to create appropriate roles, conduct periodic access reviews, enforce separation of duties (SoD) by using constrained RBAC (mutually exclusive roles).
Real command example (Active Directory):
# Add user to a role (group)
Add-ADGroupMember -Identity "HR Managers" -Members "jdoe"
# List members of a role
Get-ADGroupMember -Identity "HR Managers"Comparison at a Glance
DAC: Owner controls access; flexible but weak security; used in personal systems.
MAC: System controls access via labels; strong security; used in high-security environments.
RBAC: Roles control access; manageable for large organizations; used in enterprises.
Exam Focus: SY0-701 Specifics
The exam will ask you to identify which model is being used in a scenario. Key phrases: "owner sets permissions" → DAC; "system enforces labels" → MAC; "based on job function" → RBAC. Also know that MAC is often associated with Bell-LaPadula and Biba, while RBAC is associated with NIST and Active Directory. Trap: ABAC is not the same as RBAC; ABAC uses attributes (user, resource, environment) to make dynamic decisions.
Step 1: Identify the Scenario
Read the scenario carefully. Look for keywords: 'owner decides' indicates DAC; 'security clearance' or 'classification labels' indicates MAC; 'job role' or 'group membership' indicates RBAC. Example: 'A user creates a file and grants read access to a colleague' → DAC. 'A system prevents a user from reading a file marked Top Secret' → MAC. 'An administrator assigns the HR role to a new employee' → RBAC.
Step 2: Determine Ownership vs. System Control
Ask: Who controls access? If the object owner (user) can change permissions, it's DAC. If the system enforces rules that users cannot override, it's MAC. If access is determined by role assignment managed by an administrator, it's RBAC. For example, on Windows, if a user right-clicks a folder and sets permissions, that's DAC. If SELinux denies access despite the owner's permissions, that's MAC.
Step 3: Check for Labels vs. Roles
MAC uses security labels (e.g., Secret, Top Secret). RBAC uses roles (e.g., Manager, Editor). If the scenario mentions 'clearance' or 'classification', it's MAC. If it mentions 'job function' or 'group', it's RBAC. Trap: Some scenarios mix elements. For example, a system that uses both DAC and MAC (like SELinux with targeted policies) — the exam will focus on the dominant model.
Step 4: Evaluate Administration Overhead
DAC has low administration overhead because users manage their own objects. MAC has high overhead because every subject and object must be labeled. RBAC has moderate overhead because roles must be defined and maintained. The exam may ask which model is best for a large organization with frequent role changes — answer RBAC.
Step 5: Map to Exam Objectives
SY0-701 Objective 1.1 expects you to compare DAC, MAC, and RBAC. Also be aware of Rule-Based Access Control (RBAC) as a separate concept — rule-based uses rules like 'allow access from 9-5', not roles. This is a common trap: the acronym RBAC can mean Role-Based or Rule-Based. The exam usually spells out 'Role-Based' or 'Rule-Based'. If you see 'RBAC' alone, assume Role-Based.
Scenario 1: Enterprise File Server Migration
A SOC analyst at a mid-size company is auditing permissions on a file server. The company uses DAC (NTFS permissions) on shared folders. The analyst finds that many users have been granted full control to folders they do not own, leading to data exposure. The correct response is to implement RBAC by creating roles (e.g., 'Finance', 'HR', 'IT') and mapping existing permissions to roles. Tools: PowerShell for Active Directory, AccessChk (Sysinternals) to audit current permissions. Common mistake: trying to fix permissions manually without role definition, which leads to inconsistent ACLs.
Scenario 2: Government Agency Data Leak
A government contractor uses a MAC system (SELinux) to protect classified documents. An engineer accidentally assigns a 'Secret' label to a file that should be 'Top Secret'. A user with Secret clearance reads the file, violating policy. The analyst detects this via audit logs showing an unexpected access to a Secret-labeled file by a Secret-cleared user. The correct response is to re-label the file and investigate if the user accessed other mislabeled files. Tools: ausearch (auditd), sealert for SELinux alerts. Common mistake: assuming MAC prevents all leaks — it only enforces labels; mislabeling is a human error.
Scenario 3: Cloud IAM Role Explosion
A cloud administrator uses RBAC in AWS IAM. Over time, dozens of roles are created for specific functions (e.g., 'S3ReadOnly', 'EC2StartStop'). An auditor finds that a user has been assigned multiple roles, giving them more permissions than needed (role creep). The correct response is to conduct a role mining exercise using AWS IAM Access Analyzer to identify unused permissions and consolidate roles. Tools: AWS IAM Access Analyzer, AWS CloudTrail logs. Common mistake: creating a new role for every task instead of using policy conditions or attribute-based access control (ABAC).
What SY0-701 Tests on This Objective
Objective 1.1 requires you to compare and contrast access control models. The exam will present scenario-based questions where you must identify the model being used. Sub-objectives include:
Distinguish between DAC, MAC, and RBAC.
Recognize that MAC uses labels and is associated with Bell-LaPadula and Biba.
Understand that RBAC is based on roles and is common in enterprises.
Know that DAC allows object owners to set permissions.
Common Wrong Answers and Why
Choosing DAC when the scenario mentions 'security clearance' – Candidates confuse 'clearance' with 'permissions'. Clearance is a label, a MAC concept.
Choosing MAC when the scenario says 'administrator assigns permissions' – Administration does not imply MAC; RBAC also involves administrators assigning roles.
Confusing Role-Based with Rule-Based – Both abbreviate to RBAC. The exam will spell out 'Role-Based' or 'Rule-Based'. Rule-Based uses conditions like time-of-day, not roles.
Thinking DAC is always insecure – DAC is appropriate for personal files; it's not inherently insecure, just less restrictive.
Specific Terms and Acronyms
DAC: Discretionary Access Control
MAC: Mandatory Access Control (not to be confused with Media Access Control)
RBAC: Role-Based Access Control
ABAC: Attribute-Based Access Control (not on SY0-701 but may appear as a distractor)
Bell-LaPadula: Confidentiality model (no read up, no write down)
Biba: Integrity model (no read down, no write up)
Common Trick Questions
Scenario: 'A file owner grants read access to another user.' Answer: DAC.
Scenario: 'A system prevents a user from writing to a file with a lower classification.' Answer: MAC (Bell-LaPadula).
Scenario: 'A user is granted access because they are a member of the Sales group.' Answer: RBAC.
Trick: 'A system uses rules like 'allow access if time is between 9-5'.' This is Rule-Based Access Control, not Role-Based.
Decision Rule for Eliminating Wrong Answers
If the scenario mentions 'owner decides' or 'user sets permissions', eliminate MAC and RBAC → answer DAC.
If the scenario mentions 'clearance', 'classification', 'label', or 'system enforces', eliminate DAC and RBAC → answer MAC.
If the scenario mentions 'job function', 'role', 'group', or 'administrator assigns role', eliminate DAC and MAC → answer RBAC.
If the scenario mentions 'conditions' like time or location, eliminate all three → answer Rule-Based (if listed) or ABAC.
DAC: object owner sets permissions; common in Windows NTFS and Linux chmod.
MAC: system enforces labels; Bell-LaPadula for confidentiality, Biba for integrity.
RBAC: access based on job role; NIST standard; reduces administrative overhead.
SY0-701 expects you to identify the model from scenario keywords: 'owner' → DAC, 'clearance' → MAC, 'role' → RBAC.
Rule-Based Access Control (also RBAC) uses conditions like time-of-day; do not confuse with Role-Based.
ABAC is not on SY0-701 but may appear as a distractor; it uses attributes for dynamic decisions.
MAC is implemented via SELinux (Linux) and Mandatory Integrity Control (Windows).
DAC is vulnerable to Trojan horses that inherit user permissions.
RBAC enforces separation of duties via mutually exclusive roles.
The exam may ask which model is best for a large organization with frequent role changes – answer RBAC.
These come up on the exam all the time. Here's how to tell them apart.
Discretionary Access Control (DAC)
Owner controls permissions
Flexible, user-friendly
Vulnerable to social engineering
Common in Windows and Linux
No security labels required
Mandatory Access Control (MAC)
System controls permissions
Rigid, high security
Resistant to user error
Common in SELinux, Trusted OS
Uses security labels (clearance, classification)
Role-Based Access Control (RBAC)
Access based on job role
Static permissions (role defines access)
Simpler administration
Common in enterprises (AD, IAM)
Can lead to role explosion
Attribute-Based Access Control (ABAC)
Access based on attributes (user, resource, environment)
Dynamic permissions (evaluated at runtime)
More complex administration
Gaining popularity in cloud (AWS, Azure)
Granular and flexible
Mistake
DAC and MAC are the same because both use permissions.
Correct
DAC allows owners to change permissions; MAC enforces system-wide labels that users cannot change. They are fundamentally different in control authority.
Mistake
RBAC is always more secure than DAC.
Correct
RBAC reduces administrative overhead but can suffer from role creep. DAC can be secure if used in a trusted environment with proper user training.
Mistake
MAC is only used in military systems.
Correct
MAC is also used in commercial systems like SELinux on Linux and Windows Mandatory Integrity Control (MIC) to protect against malware.
Mistake
The acronym RBAC always means Role-Based Access Control.
Correct
RBAC can also stand for Rule-Based Access Control. The SY0-701 exam distinguishes between the two by spelling out the full term.
Mistake
In MAC, users can delegate their access to others.
Correct
In MAC, users cannot delegate access because the system controls all permissions. Delegation is a feature of DAC, not MAC.
DAC allows the owner of an object to set permissions, while MAC enforces system-wide labels that users cannot override. On the exam, if the scenario says 'the owner decides', it's DAC. If it says 'security clearance' or 'classification', it's MAC. Example: A user sharing a folder in Windows is DAC; SELinux denying access despite owner permissions is MAC.
No. RBAC (Role-Based) assigns permissions based on job roles. Rule-Based Access Control uses conditions like time of day or location. Both abbreviate to RBAC, but the exam spells out the full term. For example, 'allow access only during business hours' is Rule-Based, not Role-Based.
MAC is best because it enforces mandatory labels and prevents users from accidentally or intentionally leaking classified data. DAC would be too permissive, and RBAC does not enforce classification levels.
Bell-LaPadula is a MAC model focused on confidentiality. It enforces 'no read up' (subjects cannot read objects at a higher classification) and 'no write down' (subjects cannot write to objects at a lower classification). On the exam, if you see these rules, answer MAC.
Yes. For example, SELinux (MAC) can enforce policies on top of Linux discretionary permissions (DAC). The system first checks DAC, then MAC. If either denies, access is denied. The exam may present a scenario where both are used; focus on the dominant model described.
A common trap is confusing 'role-based' with 'rule-based' because both are called RBAC. Another trap is thinking MAC is only for military – it's also in SELinux. Also, some questions describe ABAC (attribute-based) as a distractor; remember ABAC is not on SY0-701.
Think 'Mandatory' = 'Mandatory Labels'. MAC requires every subject and object to have a label. DAC and RBAC do not use labels. If the scenario mentions 'clearance', 'classification', or 'security label', it's MAC.
You've just covered Access Control Models (DAC, MAC, RBAC) — now see how well it sticks with free SY0-701 practice questions. Full explanations included, no account needed.
Done with this chapter?