CompTIA Security+ Access Control Models - RBAC, ABAC, DAC, MAC, Zero-Fluff Guide

CompTIA Security+ Access Control Models: RBAC, ABAC, DAC, MAC – Zero-Fluff Guide

1. What This Is & Why It Matters

Access control models define who can do what in your systems. If you mess this up, you get: - Data breaches (e.g., an intern accidentally deleting production databases). - Compliance violations (e.g., failing an audit because contractors have admin access). - Operational chaos (e.g., no one knows who can approve changes, so everything stalls).

Real-world scenario: You’re a sysadmin at a healthcare company. A doctor needs temporary access to patient records for an emergency. Your current system (DAC) lets the doctor’s manager grant access—but what if the manager is on vacation? RBAC (role-based) would let you assign a "Temporary Clinician" role in seconds. ABAC (attribute-based) could auto-grant access if the doctor’s shift is "night emergency" and the patient’s status is "critical."

This guide will show you: ? How to implement each model in real systems (AWS, Linux, Windows). ? How to spot exam traps (e.g., "Which model enforces mandatory access?"). ? How to avoid production disasters (e.g., "Why DAC is a nightmare for compliance").

2. Core Concepts & Components

? Discretionary Access Control (DAC)

• Definition: Owners decide who gets access (e.g., "I’ll share this Google Doc with Bob").
• Production insight: Great for collaboration, terrible for security. If a user’s account is compromised, the attacker inherits all their permissions.
• Example: Linux file permissions (chmod 755 file.txt), Windows "Share" folders.

? Mandatory Access Control (MAC)

• Definition: The system enforces access based on labels (e.g., "Top Secret" vs. "Public"). Users can’t override it.
• Production insight: Used in military/government. If you’re not in the "Top Secret" clearance group, you can’t even see the file.
• Example: SELinux (Linux), Windows Mandatory Integrity Control (MIC).

? Role-Based Access Control (RBAC)

• Definition: Permissions are tied to roles (e.g., "Admin," "Auditor"), not individual users.
• Production insight: Best for scalability. Instead of managing 1,000 users, you manage 10 roles.
• Example: AWS IAM roles, Kubernetes Role/ClusterRole.

? Attribute-Based Access Control (ABAC)

• Definition: Access is granted based on attributes (e.g., "User is in Finance and it’s after 5 PM and the file is labeled ‘Confidential’").
• Production insight: Most flexible but complex. Used in cloud environments (AWS IAM policies with Condition blocks).
• Example: AWS IAM policies with aws:SourceIP, aws:CurrentTime.

? Rule of Least Privilege (RoLP)

• Definition: Users get only the permissions they need—nothing more.
• Production insight: Prevents 90% of breaches. If a hacker compromises a "Read-Only" account, they can’t delete data.

? Separation of Duties (SoD)

• Definition: Critical tasks require multiple people (e.g., one person approves a payment, another executes it).
• Production insight: Stops fraud. If one person could both approve and pay, they could steal money.

3. Step-by-Step Hands-On Implementation

? Prerequisites

• A Linux VM (Ubuntu 22.04) or AWS account (free tier).
• Basic CLI knowledge (chmod, useradd, aws iam).

? Task 1: Implement DAC (Linux File Permissions)

Goal: Restrict a file so only the owner can read/write it.

1. Create a test file: bash echo "Top Secret Data" > secret.txt ls -l secret.txt # Check current permissions (-rw-r--r--)

2. -rw-r--r-- means:

   • Owner: Read + Write (rw-)
   • Group: Read (r--)
   • Others: Read (r--)

3. Restrict access to owner only: bash chmod 600 secret.txt # Owner: RW, Group/Others: None ls -l secret.txt # Now shows -rw-------

4. Verify: bash sudo -u nobody cat secret.txt # Should fail (Permission denied)

Why this matters: If you leave files as 644 (world-readable), any user (or malware) on the system can read them.

? Task 2: Implement MAC (SELinux)

Goal: Use SELinux to block a web server from accessing a file.

1. Check SELinux status: bash sestatus # Should say "enforcing"

2. Create a restricted file: bash echo "SELinux Test" > /var/www/html/restricted.txt chmod 644 /var/www/html/restricted.txt

3. Try to access it via Apache (should fail): bash curl http://localhost/restricted.txt # 403 Forbidden

4. Check SELinux denial logs: bash grep "denied" /var/log/audit/audit.log

5. You’ll see avc: denied { read } because Apache (httpd_t) isn’t allowed to read files labeled default_t.

6. Fix it (temporarily): bash chcon -t httpd_sys_content_t /var/www/html/restricted.txt curl http://localhost/restricted.txt # Now works

Why this matters: Without MAC, a hacked web server could read any file on the system (e.g., /etc/shadow).

? Task 3: Implement RBAC (AWS IAM)

Goal: Create an IAM role for a "DevOps Engineer" with specific permissions.

1. Create a policy (JSON): json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:Describe*", "s3:ListAllMyBuckets" ], "Resource": "*" } ] } Save as devops-policy.json.

2. Create the policy in AWS: bash aws iam create-policy --policy-name DevOpsReadOnly --policy-document file://devops-policy.json

3. Create a role and attach the policy: bash aws iam create-role --role-name DevOpsEngineer --assume-role-policy-document '{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:root" }, "Action": "sts:AssumeRole" }] }' aws iam attach-role-policy --role-name DevOpsEngineer --policy-arn arn:aws:iam::123456789012:policy/DevOpsReadOnly

4. Test the role (switch to it): bash aws sts assume-role --role-arn arn:aws:iam::123456789012:role/DevOpsEngineer --role-session-name TestSession

5. Export the temporary credentials and try: bash aws ec2 describe-instances # Should work aws s3 cp s3://secret-bucket/file.txt . # Should fail (no permission)

Why this matters: If you give users individual permissions, you’ll drown in access requests. RBAC scales.

? Task 4: Implement ABAC (AWS IAM with Conditions)

Goal: Allow S3 access only from a specific IP range.

1. Create a policy with a condition: json { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "s3:*", "Resource": "*", "Condition": { "IpAddress": { "aws:SourceIp": "203.0.113.0/24" } } }] } Save as ip-restricted-s3.json.

2. Attach it to a user: bash aws iam create-policy --policy-name IPRestrictedS3 --policy-document file://ip-restricted-s3.json aws iam attach-user-policy --user-name Alice --policy-arn arn:aws:iam::123456789012:policy/IPRestrictedS3

3. Test it:

4. From an allowed IP (203.0.113.5): bash aws s3 ls # Works
5. From a blocked IP (198.51.100.5): bash aws s3 ls # Fails (Access Denied)

Why this matters: ABAC lets you enforce dynamic rules (e.g., "Only allow access during business hours").

4.-Production-Ready Best Practices

? Security

• DAC: Avoid chmod 777. Use 640 for files (rw-r-----) and 750 for directories (rwxr-x---).
• MAC: Enable SELinux/AppArmor before deploying apps. Audit logs (audit2allow) to debug denials.
• RBAC: Use AWS IAM Access Analyzer to find unused permissions.
• ABAC: Start with simple conditions (e.g., aws:SourceIP), then add complexity (e.g., aws:MultiFactorAuthPresent).

? Cost Optimization

• RBAC: Fewer roles = fewer IAM policies = lower AWS bill (IAM is free, but policy evaluations add latency).
• ABAC: Use AWS IAM Policy Simulator to test conditions before deploying.

? Reliability & Maintainability

• Naming conventions:
• Roles: Role-<Department>-<Purpose> (e.g., Role-Finance-ReadOnly).
• Policies: Policy-<Service>-<AccessLevel> (e.g., Policy-S3-ReadWrite).
• Tagging: Tag IAM roles with Environment=Prod, Owner=Alice.

? Observability

• Monitor:
• DAC: auditd logs for chmod/chown changes.
• MAC: SELinux denials (/var/log/audit/audit.log).
• RBAC/ABAC: AWS CloudTrail for AssumeRole events.
• Alerts:
• Trigger on s3:PutBucketPolicy (someone might be opening up a bucket).
• Trigger on iam:CreatePolicyVersion (someone might be backdooring a policy).

5. Common Mistakes & Traps

6.-Exam/Certification Focus (CompTIA Security+)

? Typical Question Patterns

1. "Which model enforces mandatory access?"
2. ? MAC (SELinux, military classifications).

3. RBAC (roles are assigned, not enforced by the system).

4. "You need to grant access based on job title. Which model?"

5. ? RBAC (roles = job titles).

6. ABAC (too complex for simple role-based access).

7. "A user can share files with anyone. Which model is this?"

8. ? DAC (owners decide access).

9. MAC (system enforces access).

10. "You need to restrict access to a file based on time of day. Which model?"

11. ? ABAC (conditions like aws:CurrentTime).
12. ? RBAC (static roles can’t handle time-based rules).

Trap Distinctions

7.-Hands-On Challenge (With Solution)

Challenge:

You’re a Linux admin. A developer (dev1) needs to run a script (/opt/app/deploy.sh) but gets Permission denied. The script is owned by root:root with 700 permissions. Fix it without making the script world-readable.

Solution:

sudo chown root:dev /opt/app/deploy.sh  # Change group to "dev"
sudo chmod 750 /opt/app/deploy.sh       # Owner: RWX, Group: RX, Others: None
sudo usermod -aG dev dev1               # Add dev1 to the "dev" group

Why it works: - 750 = Owner (root) has full access, group (dev) can read/execute. - dev1 is now in the dev group, so they inherit group permissions.

8.-Rapid-Reference Crib Sheet

9.-Where to Go Next

1. AWS IAM Best Practices: AWS IAM Documentation
2. SELinux for Beginners: Red Hat SELinux Guide
3. CompTIA Security+ Study Guide (Dion): Amazon Link
4. Hands-On Lab: AWS IAM Policy Simulator (Test ABAC/RBAC policies before deploying).