Authorization - Access Control

Introduction

Once the operating system has verified WHO you are (authentication), it must decide WHAT you are allowed to do. This is authorization — the process of determining whether an authenticated entity has permission to perform a requested operation on a specific resource. Authentication without authorization is useless (you know who someone is but cannot control their actions), and authorization without authentication is impossible (you cannot enforce permissions without knowing identity).

Consider a hospital: authentication is showing your staff badge at the entrance. Authorization determines which rooms you can enter — a nurse can access patient wards but not the server room; an IT technician can access the server room but not the pharmacy.

The Access Control Matrix

The theoretical foundation of authorization is the access control matrix — a table with subjects (users/processes) as rows and objects (files/resources) as columns. Each cell specifies the permitted operations.

In practice, the full matrix is too large and sparse to store directly. Two approaches decompose it:

Access Control Lists (ACLs): Store by column — for each object, list which subjects have which permissions. (Used by file systems: "who can access this file?")

Capability Lists: Store by row — for each subject, list which objects they can access and how. (Used by some research OS and modern token systems: "what can this user do?")

Access Control Models

Discretionary Access Control (DAC)

The resource owner decides who gets access. This is what Unix/Linux and Windows use by default.

How it works: When you create a file, you are the owner. You decide who can read, write, or execute it. You can grant permissions to others or revoke them.

Advantages: Flexible, intuitive, users manage their own resources. Disadvantages: Vulnerable to Trojan horses — a malicious program running as your user inherits ALL your permissions. If you can read classified files, so can any malware running under your account.

Mandatory Access Control (MAC)

The system enforces access policies that even resource owners cannot override. Every subject and object has a security label assigned by the system administrator.

How it works: The system assigns security levels (e.g., Top Secret > Secret > Confidential > Unclassified). Access rules are enforced system-wide:

• No Read Up (Simple Security Property): A subject cannot read objects at a higher classification
• No Write Down (Star Property): A subject cannot write to objects at a lower classification (prevents information leakage)

Examples: SELinux (Linux), Windows Mandatory Integrity Control Used in: Military, government, financial institutions where information leakage must be prevented.

Role-Based Access Control (RBAC)

Permissions are assigned to roles, and users are assigned to roles. Users do not get direct permissions — they inherit permissions from their roles.

Advantages:

• Easy to manage at scale (change role permissions → all users in that role updated)
• Reflects organizational structure naturally
• Simplifies auditing (who has access? → check role membership)
• Supports separation of duties (require two different roles for sensitive operations)

Used in: Enterprise systems, databases, cloud platforms (AWS IAM roles).

The Principle of Least Privilege

Every subject should have only the minimum permissions necessary to perform its intended function — nothing more. This limits damage from bugs, attacks, and human error.

Examples of least privilege:

• A web server process should only read website files, not modify system configurations
• A database backup script needs read access to the database, not write or delete
• A user editing documents should not have administrator privileges

Implementation:

Privilege Escalation

When a user or process gains higher privileges than authorized:

Vertical escalation: Normal user gains root/admin access (e.g., exploiting a buffer overflow in a setuid program)

Horizontal escalation: User A accesses User B's resources (e.g., manipulating session tokens in a web application)

Defenses:

• Minimize setuid programs (fewer opportunities for exploitation)
• Use capabilities instead of full root access (fine-grained privileges)
• Regular auditing of privilege assignments
• Containerization (even if compromised, limited escape)

Linux Capabilities

Traditional Unix has binary privilege: you are either root (can do everything) or a normal user (limited). Linux capabilities break root privilege into fine-grained units:

Access Control Implementation in File Systems

Unix Permissions (DAC)

POSIX ACLs (Extended DAC)

When basic owner/group/other is insufficient, POSIX ACLs allow per-user and per-group entries:

Key Takeaways

• Authorization determines what authenticated users can do — separate from authentication
• DAC: Owner controls access (flexible but vulnerable to Trojan horses)
• MAC: System enforces access policy (strong but rigid)
• RBAC: Permissions assigned to roles, users assigned to roles (scalable management)
• Principle of Least Privilege: Give only the minimum permissions needed
• Linux capabilities provide fine-grained alternatives to all-or-nothing root access
• Modern systems often layer multiple models (DAC + MAC + RBAC) for defense in depth