Operating SystemsFile Protection

File Protection: Securing Persistent Data

LevelIntermediate

Duration75 mins

TopicFile Protection

5 / 5

Permission Models: The Complete Access Control Landscape

From Mechanics to Policy

We've examined the mechanisms of access control—permission bits, ACLs, capabilities. But mechanisms are just tools. The meaningful question is: What security policy do you want to enforce?

A permission model defines how access control decisions are made—the rules, the actors, the relationships. Different models optimize for different concerns: flexibility, central control, auditability, or simplicity. This page synthesizes everything we've learned and places it in the broader context of security policy frameworks used in modern systems.

Understanding these models enables you to choose the right approach for your security requirements, whether you're configuring a single server, designing a multi-tenant cloud platform, or implementing an enterprise security architecture.

What You Will Learn

By the end of this page, you will understand: the distinction between Discretionary (DAC) and Mandatory (MAC) access control, how Role-Based Access Control (RBAC) simplifies permission management, Attribute-Based Access Control (ABAC) for policy-based decisions, how these models compose in real systems (SELinux, AppArmor, Windows), and how to choose the right model for your security requirements.

Discretionary Access Control (DAC)

Discretionary Access Control is the model we've studied throughout this module. "Discretionary" means that the resource owner has discretion—complete control—over who can access their resources.

In DAC:

File owners set permissions
Owners can grant access to anyone
Owners can revoke access at will
There's no system-enforced policy beyond owner control

DAC Characteristics

•Ownership-centered — The file owner determines access policy. No higher authority overrides owner decisions.
•Flexible sharing — Owners can grant access to collaborators without administrator involvement.
•User empowerment — Users control their own data. This respects user autonomy.
•Decentralized policy — No central repository of "who can access what." Policies are distributed across file ACLs.
•Identity-based — Permissions are granted to users (identities), not roles or clearances.

Unix permissions and ACLs are DAC:

When you create a file, you own it. You can chmod it to be world-readable, or restrict it to yourself. You can add ACL entries granting specific users access. The system doesn't question your choices.

The fundamental weakness of DAC:

DAC cannot enforce global policies. If the security goal is "classified documents must never leave the secure network," DAC can't guarantee it. An owner with access to a classified file can simply chmod it to world-readable, or copy it somewhere accessible. DAC trusts owners completely—problematic when owners might be compromised, malicious, or simply careless.

DAC Cannot Prevent Data Exfiltration

If Alice has read access to secret.txt, she can copy its contents to public.txt (which she owns and makes world-readable). DAC checks permissions on each operation but cannot track data flow. Once you can read data, you can copy it anywhere you have write access. This is called the information flow problem.

Mandatory Access Control (MAC)

Mandatory Access Control is the counterpoint to DAC. "Mandatory" means the system—not users—enforces access policy. Owners cannot override system-level rules, regardless of their desires or even their ownership.

MAC was developed for military and government systems where data classification (Top Secret, Secret, Unclassified) must be enforced regardless of user actions. Even if an administrator owns a Top Secret file, they cannot make it accessible to Unclassified users.

DAC vs MAC: Fundamental Differences
Aspect	DAC	MAC
Who controls access?	Resource owner	System policy
Can owner override?	Yes (owner is god)	No (system overrides owner)
Policy location	Per-object (ACLs)	System-wide rules
Trust model	Trust owners to be competent	Trust only the security administrator
Information flow	Not controlled	Strictly controlled (no write-down, no read-up)
Typical use case	General-purpose systems	Classified environments, high-security systems
User freedom	High	Restricted
Admin complexity	Lower	Higher (policy maintenance)

The Bell-LaPadula Model:

The classic MAC model assigns security labels (clearances) to subjects and objects. Rules:

No read up — A subject cannot read objects above their clearance
No write down — A subject cannot write to objects below their clearance (prevents leaking to lower levels)

This prevents both direct access violations and indirect information flow (copying Secret data to Unclassified files).

bell_lapadula.txt

Bell-LaPadula

Bell-LaPadula Model Example:
 
Security Levels (Hierarchy):
    TOP SECRET (TS)
        ↑
    SECRET (S)
        ↑  
    CONFIDENTIAL (C)
        ↑
    UNCLASSIFIED (U)
 
Subject (User) Clearances:
    General: TOP SECRET
    Colonel: SECRET  
    Private: UNCLASSIFIED
 
Object (File) Classifications:
    battle_plans.txt:     SECRET
    personnel.txt:        CONFIDENTIAL
    cafeteria_menu.txt:   UNCLASSIFIED
 
Access Matrix (Bell-LaPadula Rules):
 
                    TOP SECRET   SECRET    CONFIDENTIAL   UNCLASSIFIED
                    files        files     files          files
General (TS)        Read/Write   Read/Write  Read-Only     Read-Only
Colonel (S)         ✗            Read/Write  Read-Only     Read-Only
Private (U)         ✗            ✗           ✗             Read/Write
 
Key Rules:
• No Read Up: Colonel cannot read TOP SECRET files
• No Write Down: General cannot write to UNCLASSIFIED files
  (This prevents copying TOP SECRET content to UNCLASSIFIED!)
 
Even if General OWNS cafeteria_menu.txt, they cannot write to it!
The mandatory policy overrides ownership.

MAC In Practice

Pure Bell-LaPadula is rare outside classified environments. But MAC principles appear in: SELinux (type enforcement), AppArmor (path-based restrictions), Windows Mandatory Integrity Control (MIC), and iOS/Android app sandboxing. These systems layer mandatory restrictions over DAC.

Role-Based Access Control (RBAC)

Role-Based Access Control introduces an abstraction layer between users and permissions. Instead of granting permissions directly to users, you:

Define roles (collections of permissions)
Assign users to roles

This decoupling dramatically simplifies administration, especially in large organizations where permissions map to job functions.

rbac_example.txt

RBAC Example

RBAC Structure:
 
┌─────────────────────────────────────────────────────────────────┐
│                          USERS                                   │
│   alice    bob    carol    dave    eve    frank    grace        │
└─────────┬──────┬──────────────┬──────────┬──────────────────────┘
          │      │              │          │
     ┌────▼──────▼───┐    ┌────▼────┐  ┌──▼────────┐
     │   developer   │    │ manager │  │  auditor  │
     │    (ROLE)     │    │ (ROLE)  │  │  (ROLE)   │
     └───────┬───────┘    └────┬────┘  └─────┬─────┘
             │                 │              │
        Permissions:      Permissions:   Permissions:
        - read code       - read code    - read logs
        - write code      - read reports - read reports
        - run builds      - approve PRs  - view metadata
        - read docs       - view budgets - (read-only everywhere)
 
Compared to Direct Assignment (no roles):
 
Without RBAC:
  alice: read_code, write_code, run_builds, read_docs
  bob:   read_code, write_code, run_builds, read_docs
  carol: read_code, write_code, run_builds, read_docs
  ...
  (If permissions change, update every user)
 
With RBAC:  
  alice → developer
  bob → developer
  carol → developer
  (If permissions change, update the role once)
 
When alice gets promoted to manager:
  Just: remove alice from developer, add alice to manager
  (All permission changes happen automatically)

RBAC advantages:

Why Organizations Adopt RBAC

•Simplified administration — Change permissions by modifying roles, not individual users. One role change affects all assigned users.
•Auditability — Clear mapping: "What can developers do?" (Check the role.) "What role does Alice have?" (Check assignments.)
•Policy alignment — Roles map to job functions, making access policies match organizational structure.
•On/offboarding efficiency — New employee gets assigned to roles. Departing employee: remove from all roles. No per-resource updates.
•Least privilege enforcement — Define minimal roles; users get only what their job requires.
•Separation of duties — Prevent single users from having dangerous permission combinations by excluding role combinations.

RBAC in operating systems:

SELinux roles — Part of SELinux context (user:role:type:level)
sudo — Grant commands to users/groups (essentially role-like)
Windows groups — Groups function as primitive roles; permissions granted to groups
Cloud IAM — AWS IAM roles, GCP roles, Azure RBAC roles all implement this model

Hierarchical RBAC

Advanced RBAC supports role hierarchies: senior_developer inherits all permissions from developer plus additional ones. This mirrors organizational hierarchies and reduces permission overlap management.

Attribute-Based Access Control (ABAC)

Attribute-Based Access Control is the most flexible model. Instead of fixed roles or ACLs, access decisions are made by evaluating policies against attributes of:

Subject — Who is requesting (department, clearance, location, time of login)
Object — What is being accessed (classification, owner, creation date)
Action — What operation (read, write, approve)
Environment — Context (time of day, network location, threat level)

abac_policies.txt

ABAC Policy

ABAC Policy Examples (pseudocode):
 
Policy 1: "Employees can only access their department's files"
───────────────────────────────────────────────────────────
PERMIT IF:
    subject.type == "employee" AND
    subject.department == resource.department
 
Policy 2: "Contractors can only access during business hours"
───────────────────────────────────────────────────────────
PERMIT IF:
    subject.type == "contractor" AND
    environment.time >= 09:00 AND
    environment.time <= 17:00 AND
    environment.day NOT IN ("Saturday", "Sunday")
 
Policy 3: "Sensitive documents require encrypted connection"
───────────────────────────────────────────────────────────  
PERMIT IF:
    resource.sensitivity_level == "high" IMPLIES
    environment.connection_encrypted == true
 
Policy 4: "Managers can approve expenses up to their limit"
───────────────────────────────────────────────────────────
PERMIT IF:
    action == "approve_expense" AND
    subject.role == "manager" AND
    resource.amount <= subject.expense_limit
 
Policy 5: "Medical records require patient consent or emergency"
───────────────────────────────────────────────────────────
PERMIT IF:
    resource.type == "medical_record" AND
    (subject.id == resource.patient_id OR
     resource.has_patient_consent == true OR
     environment.emergency_mode == true)

ABAC compared to other models:

Access Control Model Comparison
Model	Decision Based On	Flexibility	Complexity	Best For
DAC	Owner's discretion	Medium	Low	Personal files, small teams
MAC	Classification labels	Low (rigid)	Medium	Military, classified systems
RBAC	Role membership	Medium	Medium	Enterprises, defined job functions
ABAC	Dynamic attributes	Very High	High	Complex policies, dynamic environments

XACML — The ABAC standard:

The eXtensible Access Control Markup Language (XACML) is an OASIS standard for expressing ABAC policies. It defines:

Policy Decision Point (PDP) — Evaluates requests against policies
Policy Enforcement Point (PEP) — Intercepts access requests, queries PDP, enforces decision
Policy Information Point (PIP) — Provides attribute values (user attributes from LDAP, etc.)
Policy Administration Point (PAP) — Where administrators define policies

ABAC in Modern Systems

Cloud platforms increasingly use ABAC:

AWS IAM Policies with conditions (time, IP, MFA status)
Azure ABAC for storage based on blob tags
Kubernetes ABAC mode (though RBAC is more common)
Open Policy Agent (OPA) for cloud-native policy

Operating systems rarely use pure ABAC, but conditional policies in SELinux and AppArmor incorporate ABAC concepts.

SELinux: Mandatory Access Control in Linux

Security-Enhanced Linux (SELinux) is the most comprehensive MAC implementation for Linux. Developed by the NSA, it adds mandatory access control that operates alongside (and supersedes) traditional DAC.

SELinux security contexts:

Every process and file has a security context with four components:

user:role:type:level

user — SELinux user (not the same as Unix UID)
role — RBAC role (what types the user can transition to)
type/domain — The crucial component; controls what can interact with what
level — MLS/MCS level (optional; for classified environments)

selinux.sh
Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
# Viewing SELinux contexts
 
$ ls -Z /etc/passwd /var/www/html/index.html
system_u:object_r:passwd_file_t:s0      /etc/passwd
system_u:object_r:httpd_sys_content_t:s0 /var/www/html/index.html
 
$ ps -Z | grep httpd
system_u:system_r:httpd_t:s0   1234 ?   00:00:01 httpd
 
# The web server (httpd) runs in domain httpd_t
# Web content files have type httpd_sys_content_t
# Password file has type passwd_file_t
 
# SELinux type enforcement rules (simplified):
#   allow httpd_t httpd_sys_content_t:file { read };
#     → httpd can read web content files
#
#   No rule for: httpd_t passwd_file_t:file { read };
#     → httpd CANNOT read passwd, even if DAC allows it!
 
# Check if SELinux denied an operation
$ ausearch -m AVC -ts recent
type=AVC msg=audit(...): avc: denied { read } for 
  pid=1234 comm="httpd" name="secret.txt" 
  scontext=system_u:system_r:httpd_t:s0 
  tcontext=system_u:object_r:user_home_t:s0 
  tclass=file
 
# httpd tried to read a file in user's home directory
# SELinux denied it: httpd_t has no access to user_home_t
 
# Managing SELinux
$ getenforce           # Check mode: Enforcing, Permissive, Disabled
Enforcing
 
$ sudo setenforce 0    # Temporarily set to Permissive (for debugging)
$ sudo setenforce 1    # Back to Enforcing

How SELinux protects against exploits:

If an attacker exploits a vulnerability in Apache (httpd) and gains code execution:

Without SELinux: Attacker runs as the httpd user, can read any file httpd can (potentially config files, database connections, etc.)
With SELinux: Attacker is confined to httpd_t domain. Even with code execution, they can only access httpd_sys_content_t files. Cannot read user homes, cannot access password databases, cannot write to most of the filesystem.

SELinux limits the blast radius of a successful exploit.

"Just Disable SELinux" Is Wrong

When SELinux blocks something, the correct response is NOT to disable it. Instead: (1) Check if your file has the wrong context (ls -Z), (2) Fix it with restorecon -R /path or chcon, (3) If custom policy is needed, use audit2allow to generate it. Disabling SELinux removes a vital security layer.

AppArmor: Path-Based Mandatory Controls

AppArmor is an alternative MAC system used by Ubuntu, SUSE, and Debian. While SELinux uses labels (types), AppArmor uses profiles that define what paths a program can access.

Key differences from SELinux:

SELinux vs AppArmor
Aspect	SELinux	AppArmor
Basis	Labels (types) on objects	Paths (pathnames)
Scope	System-wide type enforcement	Per-program profiles
Complexity	Higher (policy language)	Lower (path patterns)
File systems	Any (labels in xattrs)	Only those with stable paths
Hard links	Same label, same access	Can bypass restrictions
Learning	Steeper curve	Easier to understand
Used by	Red Hat, Fedora, CentOS	Ubuntu, SUSE, Debian

apparmor_nginx.profile

AppArmor Profile

# AppArmor profile for nginx
# /etc/apparmor.d/usr.sbin.nginx
 
#include <tunables/global>
 
/usr/sbin/nginx {
    #include <abstractions/base>
    #include <abstractions/nameservice>
 
    # Network access
    network inet stream,
    network inet6 stream,
 
    # Configuration files (read only)
    /etc/nginx/** r,
    
    # Web content (read only)
    /var/www/html/** r,
    /srv/www/** r,
    
    # Log files (append only)
    /var/log/nginx/*.log w,
    
    # PID and socket files
    /run/nginx.pid rw,
    /run/nginx/*.sock rw,
    
    # SSL certificates (read only)
    /etc/ssl/certs/** r,
    /etc/ssl/private/** r,
    
    # Deny everything else by implicit default
    
    # Child processes
    /usr/sbin/nginx px,  # Execute with this profile
}
 
# After creating profile:
$ sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx
 
# Check status
$ sudo aa-status
apparmor module is loaded.
27 profiles are loaded.
27 profiles are in enforce mode.
   /usr/sbin/nginx

AppArmor modes:

Enforce — Violations are denied and logged
Complain — Violations are logged but allowed (for profile development)

Profile development workflow:

Put profile in complain mode: aa-complain /usr/sbin/nginx
Run the application normally
Review logs for blocked operations
Update profile to allow necessary access
Switch to enforce mode: aa-enforce /usr/sbin/nginx

AppArmor's Path-Based Weakness

AppArmor restricts by pathname, not inode. If /etc/sensitive is protected, an attacker who can create a hard link at /tmp/accessible pointing to the same inode might bypass the restriction (if /tmp/ is allowed). SELinux doesn't have this issue because labels are per-inode. Consider this when choosing between systems.

Windows Security Model Overview

Windows uses a security model distinct from Unix, combining ACLs, mandatory integrity controls, and token-based access. Understanding Windows security is essential for cross-platform knowledge.

Windows Security Components

•Security Identifiers (SIDs) — Unique identifiers for users, groups, and computers. Unlike Unix UIDs, SIDs are globally unique (include a machine identifier).
•Access Tokens — Created at login, tokens contain the user's SID, group SIDs, privileges, and integrity level. Processes run with a token's authority.
•Security Descriptors — NTFS objects have security descriptors containing owner, group, DACL (discretionary ACL), and SACL (system ACL for auditing).
•DACLs with ACEs — Access Control Entries (ACEs) list (SID, rights, allow/deny). Unlike POSIX ACLs, Windows ACLs can explicitly DENY access.
•Mandatory Integrity Control (MIC) — Objects and processes have integrity levels (Low, Medium, High, System). Lower integrity cannot write to higher integrity (no write up).
•User Account Control (UAC) — Administrators run with split tokens; high-privilege operations require consent. Implements least privilege for admin users.

windows_security.ps1
PowerShell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
# Viewing Windows security information
 
# View ACL on a file
Get-Acl C:WindowsSystem32configSAM | Format-List
 
Path   : Microsoft.PowerShell.CoreFileSystem::C:WindowsSystem32configSAM
Owner  : NT AUTHORITYSYSTEM
Group  : NT AUTHORITYSYSTEM
Access : NT AUTHORITYSYSTEM Allow  FullControl
         BUILTINAdministrators Allow  FullControl
 
# View current user's token privileges
whoami /priv
 
PRIVILEGES INFORMATION
----------------------
Privilege Name                  Description                    State
=============================== ============================== ========
SeShutdownPrivilege             Shut down the system           Disabled
SeChangeNotifyPrivilege         Bypass traverse checking       Enabled
SeUndockPrivilege               Remove computer from docking   Disabled
SeIncreaseWorkingSetPrivilege   Increase a process working set Disabled
SeTimeZonePrivilege             Change the time zone           Disabled
 
# View process integrity level
whoami /groups | findstr "Mandatory"
Mandatory LabelMedium Mandatory Level   Label  S-1-16-8192
 
# Integrity Levels:
# S-1-16-0     = Untrusted
# S-1-16-4096  = Low (e.g., browser sandboxed tabs)
# S-1-16-8192  = Medium (normal user)
# S-1-16-12288 = High (elevated/admin)
# S-1-16-16384 = System

Windows DENY ACEs

Unlike POSIX ACLs (which can only grant), Windows ACLs can explicitly DENY. DENY ACEs are evaluated first, so a DENY for a user takes precedence over ALLOW for their group. This enables fine-grained restrictions but can create confusing permission outcomes if not carefully managed.

Choosing the Right Access Control Model

With multiple models available, how do you choose? The answer depends on your security requirements, operational constraints, and threat model.

Model Selection Guide
Requirement	Recommended Model	Reasoning
Personal file management	DAC (Unix perms)	Simple, user-controlled, no admin overhead
Small team collaboration	DAC + groups	Group-based sharing sufficient; familiar tools
Enterprise with defined roles	RBAC (via groups or IAM)	Maps to org structure; scalable administration
Multiple groups per file	ACLs (POSIX or NTFS)	Flexible per-file permissions beyond owner/group
Contain compromised services	MAC (SELinux/AppArmor)	Limit blast radius of exploits
Data classification required	MAC (w/ MLS)	Enforce confidentiality levels system-wide
Context-dependent access	ABAC	Time/location/attribute based policies
Highly dynamic permissions	Capabilities	Fine-grained, delegable, ephemeral access tokens
Defense in depth	DAC + MAC + RBAC	Layer models for comprehensive protection

Real systems layer models:

Production environments rarely use a single model:

Linux server: DAC (file permissions) + SELinux (MAC) + sudo (role-like privilege)
Enterprise Windows: NTFS ACLs (DAC with groups for RBAC) + MIC (MAC) + Active Directory policies
Cloud platform: IAM RBAC (role-based) + resource policies (ABAC conditions) + VPC/network isolation
Container: Host DAC + namespace isolation + seccomp (capability-like restriction) + AppArmor/SELinux

Start Simple, Add Layers As Needed

Don't over-engineer access control. Start with DAC and good group design. Add MAC only if you need containment beyond what users can configure. Add RBAC when administrative overhead becomes a problem. Each layer adds complexity—make sure you need it before implementing it.

Summary: Permission Models

Key Takeaways

•DAC — Owner-controlled permissions. Flexible but cannot enforce global policies or prevent data exfiltration.
•MAC — System-controlled permissions that override owners. Used for classified environments and exploit containment (SELinux, AppArmor).
•RBAC — Permissions assigned to roles, users assigned to roles. Simplifies administration for organizations with defined job functions.
•ABAC — Dynamic policy evaluation against attributes of subject, object, action, and environment. Maximum flexibility for complex policies.
•SELinux — Linux MAC using type enforcement. Powerful but complex. Labels every object and process.
•AppArmor — Linux MAC using path-based profiles. Simpler but path-based (vulnerable to hard link tricks).
•Windows — Combines token-based ACLs with mandatory integrity control and privilege separation (UAC).
•Layer models — Real systems combine DAC + MAC + RBAC for defense in depth.
•Choose based on requirements — Match model complexity to actual security needs.

Module Complete:

You've now completed the File Protection module, covering:

Access Control Fundamentals — The subject-object-operation model, security principles, and access matrices
User/Group/World — Unix's elegant 9-bit permission model
Access Control Lists — Fine-grained per-user and per-group permissions
Capabilities — Unforgeable tokens that unify naming and authority
Permission Models — DAC, MAC, RBAC, ABAC, and how they compose

With this comprehensive understanding of file protection, you can effectively secure systems at any scale—from personal workstations to enterprise data centers to cloud-native platforms.

Module Complete

You now have a world-class understanding of file protection mechanisms—from the theoretical foundations of access control to the practical implementation in Unix permissions, ACLs, capabilities, and MAC systems like SELinux. You understand when to apply each model and how they layer in production systems. This knowledge is fundamental to operating system security and system administration.

5 / 5

Loading learning content...

Operating SystemsFile Protection

File Protection: Securing Persistent Data

LevelIntermediate

Duration75 mins

TopicFile Protection

5 / 5

Permission Models: The Complete Access Control Landscape

From Mechanics to Policy

We've examined the mechanisms of access control—permission bits, ACLs, capabilities. But mechanisms are just tools. The meaningful question is: What security policy do you want to enforce?

What You Will Learn

Discretionary Access Control (DAC)

In DAC:

File owners set permissions
Owners can grant access to anyone
Owners can revoke access at will
There's no system-enforced policy beyond owner control

DAC Characteristics

•Ownership-centered — The file owner determines access policy. No higher authority overrides owner decisions.
•Flexible sharing — Owners can grant access to collaborators without administrator involvement.
•User empowerment — Users control their own data. This respects user autonomy.
•Decentralized policy — No central repository of "who can access what." Policies are distributed across file ACLs.
•Identity-based — Permissions are granted to users (identities), not roles or clearances.

Unix permissions and ACLs are DAC:

The fundamental weakness of DAC:

DAC Cannot Prevent Data Exfiltration

Mandatory Access Control (MAC)

DAC vs MAC: Fundamental Differences
Aspect	DAC	MAC
Who controls access?	Resource owner	System policy
Can owner override?	Yes (owner is god)	No (system overrides owner)
Policy location	Per-object (ACLs)	System-wide rules
Trust model	Trust owners to be competent	Trust only the security administrator
Information flow	Not controlled	Strictly controlled (no write-down, no read-up)
Typical use case	General-purpose systems	Classified environments, high-security systems
User freedom	High	Restricted
Admin complexity	Lower	Higher (policy maintenance)

The Bell-LaPadula Model:

The classic MAC model assigns security labels (clearances) to subjects and objects. Rules:

No read up — A subject cannot read objects above their clearance
No write down — A subject cannot write to objects below their clearance (prevents leaking to lower levels)

This prevents both direct access violations and indirect information flow (copying Secret data to Unclassified files).

bell_lapadula.txt

Bell-LaPadula

Bell-LaPadula Model Example:
 
Security Levels (Hierarchy):
    TOP SECRET (TS)
        ↑
    SECRET (S)
        ↑  
    CONFIDENTIAL (C)
        ↑
    UNCLASSIFIED (U)
 
Subject (User) Clearances:
    General: TOP SECRET
    Colonel: SECRET  
    Private: UNCLASSIFIED
 
Object (File) Classifications:
    battle_plans.txt:     SECRET
    personnel.txt:        CONFIDENTIAL
    cafeteria_menu.txt:   UNCLASSIFIED
 
Access Matrix (Bell-LaPadula Rules):
 
                    TOP SECRET   SECRET    CONFIDENTIAL   UNCLASSIFIED
                    files        files     files          files
General (TS)        Read/Write   Read/Write  Read-Only     Read-Only
Colonel (S)         ✗            Read/Write  Read-Only     Read-Only
Private (U)         ✗            ✗           ✗             Read/Write
 
Key Rules:
• No Read Up: Colonel cannot read TOP SECRET files
• No Write Down: General cannot write to UNCLASSIFIED files
  (This prevents copying TOP SECRET content to UNCLASSIFIED!)
 
Even if General OWNS cafeteria_menu.txt, they cannot write to it!
The mandatory policy overrides ownership.

MAC In Practice

Role-Based Access Control (RBAC)

Role-Based Access Control introduces an abstraction layer between users and permissions. Instead of granting permissions directly to users, you:

Define roles (collections of permissions)
Assign users to roles

This decoupling dramatically simplifies administration, especially in large organizations where permissions map to job functions.

rbac_example.txt

RBAC Example

RBAC Structure:
 
┌─────────────────────────────────────────────────────────────────┐
│                          USERS                                   │
│   alice    bob    carol    dave    eve    frank    grace        │
└─────────┬──────┬──────────────┬──────────┬──────────────────────┘
          │      │              │          │
     ┌────▼──────▼───┐    ┌────▼────┐  ┌──▼────────┐
     │   developer   │    │ manager │  │  auditor  │
     │    (ROLE)     │    │ (ROLE)  │  │  (ROLE)   │
     └───────┬───────┘    └────┬────┘  └─────┬─────┘
             │                 │              │
        Permissions:      Permissions:   Permissions:
        - read code       - read code    - read logs
        - write code      - read reports - read reports
        - run builds      - approve PRs  - view metadata
        - read docs       - view budgets - (read-only everywhere)
 
Compared to Direct Assignment (no roles):
 
Without RBAC:
  alice: read_code, write_code, run_builds, read_docs
  bob:   read_code, write_code, run_builds, read_docs
  carol: read_code, write_code, run_builds, read_docs
  ...
  (If permissions change, update every user)
 
With RBAC:  
  alice → developer
  bob → developer
  carol → developer
  (If permissions change, update the role once)
 
When alice gets promoted to manager:
  Just: remove alice from developer, add alice to manager
  (All permission changes happen automatically)

RBAC advantages:

Why Organizations Adopt RBAC

•Simplified administration — Change permissions by modifying roles, not individual users. One role change affects all assigned users.
•Auditability — Clear mapping: "What can developers do?" (Check the role.) "What role does Alice have?" (Check assignments.)
•Policy alignment — Roles map to job functions, making access policies match organizational structure.
•On/offboarding efficiency — New employee gets assigned to roles. Departing employee: remove from all roles. No per-resource updates.
•Least privilege enforcement — Define minimal roles; users get only what their job requires.
•Separation of duties — Prevent single users from having dangerous permission combinations by excluding role combinations.

RBAC in operating systems:

SELinux roles — Part of SELinux context (user:role:type:level)
sudo — Grant commands to users/groups (essentially role-like)
Windows groups — Groups function as primitive roles; permissions granted to groups
Cloud IAM — AWS IAM roles, GCP roles, Azure RBAC roles all implement this model

Hierarchical RBAC

Attribute-Based Access Control (ABAC)

Attribute-Based Access Control is the most flexible model. Instead of fixed roles or ACLs, access decisions are made by evaluating policies against attributes of:

Subject — Who is requesting (department, clearance, location, time of login)
Object — What is being accessed (classification, owner, creation date)
Action — What operation (read, write, approve)
Environment — Context (time of day, network location, threat level)

abac_policies.txt

ABAC Policy

ABAC Policy Examples (pseudocode):
 
Policy 1: "Employees can only access their department's files"
───────────────────────────────────────────────────────────
PERMIT IF:
    subject.type == "employee" AND
    subject.department == resource.department
 
Policy 2: "Contractors can only access during business hours"
───────────────────────────────────────────────────────────
PERMIT IF:
    subject.type == "contractor" AND
    environment.time >= 09:00 AND
    environment.time <= 17:00 AND
    environment.day NOT IN ("Saturday", "Sunday")
 
Policy 3: "Sensitive documents require encrypted connection"
───────────────────────────────────────────────────────────  
PERMIT IF:
    resource.sensitivity_level == "high" IMPLIES
    environment.connection_encrypted == true
 
Policy 4: "Managers can approve expenses up to their limit"
───────────────────────────────────────────────────────────
PERMIT IF:
    action == "approve_expense" AND
    subject.role == "manager" AND
    resource.amount <= subject.expense_limit
 
Policy 5: "Medical records require patient consent or emergency"
───────────────────────────────────────────────────────────
PERMIT IF:
    resource.type == "medical_record" AND
    (subject.id == resource.patient_id OR
     resource.has_patient_consent == true OR
     environment.emergency_mode == true)

ABAC compared to other models:

Access Control Model Comparison
Model	Decision Based On	Flexibility	Complexity	Best For
DAC	Owner's discretion	Medium	Low	Personal files, small teams
MAC	Classification labels	Low (rigid)	Medium	Military, classified systems
RBAC	Role membership	Medium	Medium	Enterprises, defined job functions
ABAC	Dynamic attributes	Very High	High	Complex policies, dynamic environments

XACML — The ABAC standard:

The eXtensible Access Control Markup Language (XACML) is an OASIS standard for expressing ABAC policies. It defines:

Policy Decision Point (PDP) — Evaluates requests against policies
Policy Enforcement Point (PEP) — Intercepts access requests, queries PDP, enforces decision
Policy Information Point (PIP) — Provides attribute values (user attributes from LDAP, etc.)
Policy Administration Point (PAP) — Where administrators define policies

ABAC in Modern Systems

Cloud platforms increasingly use ABAC:

AWS IAM Policies with conditions (time, IP, MFA status)
Azure ABAC for storage based on blob tags
Kubernetes ABAC mode (though RBAC is more common)
Open Policy Agent (OPA) for cloud-native policy

Operating systems rarely use pure ABAC, but conditional policies in SELinux and AppArmor incorporate ABAC concepts.

SELinux: Mandatory Access Control in Linux

SELinux security contexts:

Every process and file has a security context with four components:

user:role:type:level

user — SELinux user (not the same as Unix UID)
role — RBAC role (what types the user can transition to)
type/domain — The crucial component; controls what can interact with what
level — MLS/MCS level (optional; for classified environments)

selinux.sh
Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
# Viewing SELinux contexts
 
$ ls -Z /etc/passwd /var/www/html/index.html
system_u:object_r:passwd_file_t:s0      /etc/passwd
system_u:object_r:httpd_sys_content_t:s0 /var/www/html/index.html
 
$ ps -Z | grep httpd
system_u:system_r:httpd_t:s0   1234 ?   00:00:01 httpd
 
# The web server (httpd) runs in domain httpd_t
# Web content files have type httpd_sys_content_t
# Password file has type passwd_file_t
 
# SELinux type enforcement rules (simplified):
#   allow httpd_t httpd_sys_content_t:file { read };
#     → httpd can read web content files
#
#   No rule for: httpd_t passwd_file_t:file { read };
#     → httpd CANNOT read passwd, even if DAC allows it!
 
# Check if SELinux denied an operation
$ ausearch -m AVC -ts recent
type=AVC msg=audit(...): avc: denied { read } for 
  pid=1234 comm="httpd" name="secret.txt" 
  scontext=system_u:system_r:httpd_t:s0 
  tcontext=system_u:object_r:user_home_t:s0 
  tclass=file
 
# httpd tried to read a file in user's home directory
# SELinux denied it: httpd_t has no access to user_home_t
 
# Managing SELinux
$ getenforce           # Check mode: Enforcing, Permissive, Disabled
Enforcing
 
$ sudo setenforce 0    # Temporarily set to Permissive (for debugging)
$ sudo setenforce 1    # Back to Enforcing

How SELinux protects against exploits:

If an attacker exploits a vulnerability in Apache (httpd) and gains code execution:

Without SELinux: Attacker runs as the httpd user, can read any file httpd can (potentially config files, database connections, etc.)
With SELinux: Attacker is confined to httpd_t domain. Even with code execution, they can only access httpd_sys_content_t files. Cannot read user homes, cannot access password databases, cannot write to most of the filesystem.

SELinux limits the blast radius of a successful exploit.

"Just Disable SELinux" Is Wrong

AppArmor: Path-Based Mandatory Controls

AppArmor is an alternative MAC system used by Ubuntu, SUSE, and Debian. While SELinux uses labels (types), AppArmor uses profiles that define what paths a program can access.

Key differences from SELinux:

SELinux vs AppArmor
Aspect	SELinux	AppArmor
Basis	Labels (types) on objects	Paths (pathnames)
Scope	System-wide type enforcement	Per-program profiles
Complexity	Higher (policy language)	Lower (path patterns)
File systems	Any (labels in xattrs)	Only those with stable paths
Hard links	Same label, same access	Can bypass restrictions
Learning	Steeper curve	Easier to understand
Used by	Red Hat, Fedora, CentOS	Ubuntu, SUSE, Debian

apparmor_nginx.profile

AppArmor Profile

# AppArmor profile for nginx
# /etc/apparmor.d/usr.sbin.nginx
 
#include <tunables/global>
 
/usr/sbin/nginx {
    #include <abstractions/base>
    #include <abstractions/nameservice>
 
    # Network access
    network inet stream,
    network inet6 stream,
 
    # Configuration files (read only)
    /etc/nginx/** r,
    
    # Web content (read only)
    /var/www/html/** r,
    /srv/www/** r,
    
    # Log files (append only)
    /var/log/nginx/*.log w,
    
    # PID and socket files
    /run/nginx.pid rw,
    /run/nginx/*.sock rw,
    
    # SSL certificates (read only)
    /etc/ssl/certs/** r,
    /etc/ssl/private/** r,
    
    # Deny everything else by implicit default
    
    # Child processes
    /usr/sbin/nginx px,  # Execute with this profile
}
 
# After creating profile:
$ sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx
 
# Check status
$ sudo aa-status
apparmor module is loaded.
27 profiles are loaded.
27 profiles are in enforce mode.
   /usr/sbin/nginx

AppArmor modes:

Enforce — Violations are denied and logged
Complain — Violations are logged but allowed (for profile development)

Profile development workflow:

Put profile in complain mode: aa-complain /usr/sbin/nginx
Run the application normally
Review logs for blocked operations
Update profile to allow necessary access
Switch to enforce mode: aa-enforce /usr/sbin/nginx

AppArmor's Path-Based Weakness

Windows Security Model Overview

Windows uses a security model distinct from Unix, combining ACLs, mandatory integrity controls, and token-based access. Understanding Windows security is essential for cross-platform knowledge.

Windows Security Components

•Security Identifiers (SIDs) — Unique identifiers for users, groups, and computers. Unlike Unix UIDs, SIDs are globally unique (include a machine identifier).
•Access Tokens — Created at login, tokens contain the user's SID, group SIDs, privileges, and integrity level. Processes run with a token's authority.
•Security Descriptors — NTFS objects have security descriptors containing owner, group, DACL (discretionary ACL), and SACL (system ACL for auditing).
•DACLs with ACEs — Access Control Entries (ACEs) list (SID, rights, allow/deny). Unlike POSIX ACLs, Windows ACLs can explicitly DENY access.
•Mandatory Integrity Control (MIC) — Objects and processes have integrity levels (Low, Medium, High, System). Lower integrity cannot write to higher integrity (no write up).
•User Account Control (UAC) — Administrators run with split tokens; high-privilege operations require consent. Implements least privilege for admin users.

windows_security.ps1
PowerShell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
# Viewing Windows security information
 
# View ACL on a file
Get-Acl C:WindowsSystem32configSAM | Format-List
 
Path   : Microsoft.PowerShell.CoreFileSystem::C:WindowsSystem32configSAM
Owner  : NT AUTHORITYSYSTEM
Group  : NT AUTHORITYSYSTEM
Access : NT AUTHORITYSYSTEM Allow  FullControl
         BUILTINAdministrators Allow  FullControl
 
# View current user's token privileges
whoami /priv
 
PRIVILEGES INFORMATION
----------------------
Privilege Name                  Description                    State
=============================== ============================== ========
SeShutdownPrivilege             Shut down the system           Disabled
SeChangeNotifyPrivilege         Bypass traverse checking       Enabled
SeUndockPrivilege               Remove computer from docking   Disabled
SeIncreaseWorkingSetPrivilege   Increase a process working set Disabled
SeTimeZonePrivilege             Change the time zone           Disabled
 
# View process integrity level
whoami /groups | findstr "Mandatory"
Mandatory LabelMedium Mandatory Level   Label  S-1-16-8192
 
# Integrity Levels:
# S-1-16-0     = Untrusted
# S-1-16-4096  = Low (e.g., browser sandboxed tabs)
# S-1-16-8192  = Medium (normal user)
# S-1-16-12288 = High (elevated/admin)
# S-1-16-16384 = System

Windows DENY ACEs

Choosing the Right Access Control Model

With multiple models available, how do you choose? The answer depends on your security requirements, operational constraints, and threat model.

Model Selection Guide
Requirement	Recommended Model	Reasoning
Personal file management	DAC (Unix perms)	Simple, user-controlled, no admin overhead
Small team collaboration	DAC + groups	Group-based sharing sufficient; familiar tools
Enterprise with defined roles	RBAC (via groups or IAM)	Maps to org structure; scalable administration
Multiple groups per file	ACLs (POSIX or NTFS)	Flexible per-file permissions beyond owner/group
Contain compromised services	MAC (SELinux/AppArmor)	Limit blast radius of exploits
Data classification required	MAC (w/ MLS)	Enforce confidentiality levels system-wide
Context-dependent access	ABAC	Time/location/attribute based policies
Highly dynamic permissions	Capabilities	Fine-grained, delegable, ephemeral access tokens
Defense in depth	DAC + MAC + RBAC	Layer models for comprehensive protection

Real systems layer models:

Production environments rarely use a single model:

Linux server: DAC (file permissions) + SELinux (MAC) + sudo (role-like privilege)
Enterprise Windows: NTFS ACLs (DAC with groups for RBAC) + MIC (MAC) + Active Directory policies
Cloud platform: IAM RBAC (role-based) + resource policies (ABAC conditions) + VPC/network isolation
Container: Host DAC + namespace isolation + seccomp (capability-like restriction) + AppArmor/SELinux

Start Simple, Add Layers As Needed

Summary: Permission Models

Key Takeaways

•DAC — Owner-controlled permissions. Flexible but cannot enforce global policies or prevent data exfiltration.
•MAC — System-controlled permissions that override owners. Used for classified environments and exploit containment (SELinux, AppArmor).
•RBAC — Permissions assigned to roles, users assigned to roles. Simplifies administration for organizations with defined job functions.
•ABAC — Dynamic policy evaluation against attributes of subject, object, action, and environment. Maximum flexibility for complex policies.
•SELinux — Linux MAC using type enforcement. Powerful but complex. Labels every object and process.
•AppArmor — Linux MAC using path-based profiles. Simpler but path-based (vulnerable to hard link tricks).
•Windows — Combines token-based ACLs with mandatory integrity control and privilege separation (UAC).
•Layer models — Real systems combine DAC + MAC + RBAC for defense in depth.
•Choose based on requirements — Match model complexity to actual security needs.

Module Complete:

You've now completed the File Protection module, covering:

Access Control Fundamentals — The subject-object-operation model, security principles, and access matrices
User/Group/World — Unix's elegant 9-bit permission model
Access Control Lists — Fine-grained per-user and per-group permissions
Capabilities — Unforgeable tokens that unify naming and authority
Permission Models — DAC, MAC, RBAC, ABAC, and how they compose

With this comprehensive understanding of file protection, you can effectively secure systems at any scale—from personal workstations to enterprise data centers to cloud-native platforms.

Module Complete

5 / 5