Access Control: The Foundation of File Security - File Protection: Securing Persistent Data | OneNoughtOne

0/236

Operating SystemsFile Protection

File Protection: Securing Persistent Data

LevelIntermediate

Duration75 mins

TopicFile Protection

1 / 5

Access Control: The Foundation of File Security

Why Files Need Protection

Every file system stores data that ranges from trivial to existentially critical. Your browser cache? Ephemeral. Your company's financial records? Regulated by law. Your private SSH keys? Compromise means total system access. The operating system cannot know which files matter to whom—so it must provide universal protection mechanisms that users and administrators configure according to their needs.

File protection isn't just about preventing malicious access. It's about isolation, accountability, and controlled sharing. A multi-user system must ensure that one user's mistake or malice cannot destroy another user's data, while still enabling legitimate collaboration.

What You Will Learn

By the end of this page, you will understand: why access control is essential in any multi-user or networked system, the fundamental principles underlying all access control mechanisms, the distinction between authentication (who you are) and authorization (what you can do), and how access control decisions are made and enforced by the operating system kernel.

The Access Control Problem

At its core, access control answers a deceptively simple question: Should this operation be allowed?

When a process attempts to open a file, read its contents, modify its data, or execute it as a program, the operating system must make a decision. This decision depends on three fundamental elements:

The Three Elements of Access Control

•Subject — The entity requesting access. This is typically a process, which runs with a specific identity (user ID, group memberships, security labels). The subject is who is asking.
•Object — The resource being accessed. In file protection, this is a file or directory, but the concept extends to devices, network ports, shared memory segments, and any system resource. The object is what is being accessed.
•Operation — The action being requested. Common file operations include read, write, execute, append, delete, and change permissions. The operation is how the object will be used.

The access control decision:

Given a subject S, an object O, and an operation Op, the access control system must determine: Is S authorized to perform Op on O?

This binary decision (allow or deny) seems straightforward, but its implementation involves complex policy representation, efficient lookup mechanisms, and careful handling of edge cases. The answer depends on:

The subject's identity — Who is making the request?
The object's protection attributes — What rules govern this resource?
System-wide security policies — What global constraints apply?
The current security context — Are there temporary restrictions or elevated privileges?

The Reference Monitor Concept

Operating systems implement access control through a reference monitor—a trusted component that mediates every access request. The reference monitor must be: (1) tamper-proof—attackers cannot modify it, (2) always invoked—no access bypasses it, (3) small enough to verify—its correctness can be proven. In practice, this is the kernel's access control logic, which sits between applications and protected resources.

Authentication vs Authorization

Before diving into access control mechanisms, we must distinguish two related but fundamentally different concepts that are often confused:

Authentication answers: Who is this entity? Authorization answers: What is this entity allowed to do?

These two processes are sequential. First, the system establishes identity (authentication), then it checks what that identity permits (authorization). Access control is specifically about authorization—it assumes the subject's identity is already known.

Authentication vs Authorization: Critical Distinctions
Aspect	Authentication	Authorization
Core Question	Who are you?	What can you do?
When It Happens	At login/session start	At each resource access
Frequency	Once per session (typically)	Every operation on protected resources
Mechanisms	Passwords, biometrics, tokens, certificates	Permission bits, ACLs, capabilities, policies
Failure Mode	Access denied (identity unknown)	Operation denied (identity known but unauthorized)
Data Required	Credentials (secrets)	Policies (rules)
Primary Challenge	Verifying identity claims	Efficiently evaluating permissions

Why the distinction matters:

Strong authentication with weak authorization is dangerous. If you verify users perfectly but then grant everyone admin access, your authentication is worthless.

Conversely, sophisticated authorization rules are meaningless if attackers can impersonate legitimate users. Security requires both mechanisms working together.

The handoff point:

After authentication succeeds, the system assigns the subject a security context—a data structure containing the user's identity and security-relevant attributes. Every subsequent access control decision references this security context. In Unix, this is the process's UID and GID list. In Windows, it's the access token. In SELinux, it's the security label.

Identity Is Not What You Do

A common design mistake is conflating identity with authorization. Just because a user is a 'developer' doesn't mean they should access all development resources. Good access control separates who someone is from what they're working on, enabling fine-grained restrictions that follow the principle of least privilege.

Foundational Security Principles

Access control in operating systems is guided by time-tested security principles. These principles, established in the 1970s by Saltzer and Schroeder, remain the gold standard for secure system design:

The Saltzer-Schroeder Principles

•Principle of Least Privilege — Every subject should have only the minimum privileges needed to accomplish its task. A program that reads configuration files should not have write access. A web server serving static content should not have database access. This limits damage from bugs or compromise.
•Complete Mediation — Every access to every object must be checked. Caching authorization decisions is dangerous if permissions change. The reference monitor must be inescapable—no operation bypasses access checks.
•Fail-Safe Defaults — The default should be denial. Access must be explicitly granted, never implicitly assumed. If a permission lookup fails or returns ambiguous results, deny access. This prevents security holes from configuration errors.
•Economy of Mechanism — Security mechanisms should be as simple as possible. Complex systems have more bugs, and bugs in security code become vulnerabilities. Simple mechanisms are easier to audit, test, and trust.
•Open Design — Security should not depend on secrecy of the mechanism. The algorithm can be public; only the keys (passwords, access policies) must be secret. This enables peer review and prevents security-through-obscurity failures.
•Separation of Privilege — Require multiple conditions for access when possible. For example, both a password AND a physical token, or both manager AND compliance officer approval. Single points of failure in authorization enable single points of attack.
•Least Common Mechanism — Minimize shared mechanisms between users. Shared resources are attack vectors—if two users share a cache, one may poison it to affect the other. Isolation is safer than sharing.
•Psychological Acceptability — Security mechanisms must be usable. If users find security too burdensome, they'll circumvent it. A permission system nobody uses is no protection at all.

Applying the principles to files:

Consider how these principles manifest in file protection:

Least privilege: Users should only access files they need. A temp worker shouldn't see HR records.
Complete mediation: Every open(), read(), write() system call checks permissions.
Fail-safe defaults: Files are not world-readable by default on modern systems.
Economy of mechanism: Unix permissions use just 9 bits—simple enough to audit mentally.

These principles guide every access control design decision we'll explore in this module.

The Access Control Matrix Model

The access control matrix is the foundational theoretical model for understanding permissions. Introduced by Lampson in 1971, it represents all authorization relationships in a system.

Conceptually, visualize a spreadsheet:

Rows represent subjects (users, processes)
Columns represent objects (files, directories, devices)
Cells contain the allowed operations (read, write, execute)

Example Access Control Matrix
Subject / Object	/etc/passwd	/home/alice/secret.txt	/var/log/syslog	/bin/ls
root	read, write	read, write	read, write	read, execute
alice	read	read, write, delete	—	read, execute
bob	read	—	read	read, execute
www-data	read	—	append	read, execute

Reading the matrix:

Alice can read and write her own file (secret.txt), read /etc/passwd (which contains user info), and execute /bin/ls, but cannot access the system log.
The www-data user (web server) can only append to the log, not read previous entries—limiting what an attacker could learn from a compromised web server.
Root has full access everywhere—this is the superuser privilege.

The practical problem:

While the matrix elegantly represents access control, it cannot be implemented directly:

Space explosion: A system with 1,000 users and 1,000,000 files would need a billion cells
Sparse data: Most cells are empty (most users access few files)
Lookup efficiency: Finding a user's permissions for a file requires locating the right cell
Storage location: Where do we store this matrix on disk?

Column-wise: Access Control Lists

•Store permissions with the object
•Each file maintains a list of (subject, permissions) pairs
•Natural fit: permissions stored in file metadata
•Efficient for: 'Who can access this file?'
•Challenge: 'What can user X access?' requires scanning all files
•Examples: Unix permissions, NTFS ACLs, POSIX ACLs

Row-wise: Capability Lists

•Store permissions with the subject
•Each user/process holds a list of (object, permissions) pairs
•Natural fit: 'tickets' that grant access
•Efficient for: 'What can this user do?'
•Challenge: 'Who can access file Y?' requires checking all users
•Examples: Capability-based OSes, file descriptors (partially)

The Implementation Duality

Most real systems use column-major storage (ACLs stored with files) for persistent permissions, but row-major storage (capabilities held by processes) for runtime efficiency. When a process opens a file, the kernel checks the ACL, then issues a capability (file descriptor) for subsequent operations. This combines the administrative convenience of ACLs with the runtime efficiency of capabilities.

Access Control Enforcement in the Kernel

Understanding access control requires knowing where and when enforcement happens. The operating system kernel is the ultimate enforcer—applications cannot bypass kernel-level access checks.

The enforcement boundary:

Access control is enforced at the system call boundary. When a user-space program wants to access a file, it can't manipulate disk sectors directly. It must invoke system calls (open, read, write, etc.), and the kernel interposes on each call.

access_control_flow.txt
Access Control Flow
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
38
39
40
// The journey of a file access request
 
USER SPACE:
┌────────────────────────────────────────────────────────────────┐
│  Process (runs as user "alice")                                │
│                                                                │
│  fd = open("/home/bob/secret.txt", O_RDONLY);                  │
│      │                                                         │
│      └─── System call: passes filename, mode, process context  │
└────────────┬───────────────────────────────────────────────────┘
             │
═════════════│═══════════════════════════════════════════════════
             │  KERNEL BOUNDARY (privileged mode)
             ▼
KERNEL SPACE:
┌────────────────────────────────────────────────────────────────┐
│  1. sys_open() handler receives request                        │
│                                                                │
│  2. Path resolution: traverse "/home/bob/secret.txt"           │
│     - Check execute permission on "/" for alice                │
│     - Check execute permission on "/home" for alice            │
│     - Check execute permission on "/home/bob" for alice        │
│                                                                │
│  3. Locate inode for "secret.txt"                              │
│                                                                │
│  4. ACCESS CONTROL CHECK:                                      │
│     Subject: alice (UID=1001, GIDs=[1001, 100])                │
│     Object:  secret.txt (owner=bob, group=users, mode=0640)    │
│     Operation: read (O_RDONLY)                                 │
│                                                                │
│     owner=bob (UID=1002) → alice is not owner                  │
│     group=users (GID=100) → alice IS member                    │
│     group permissions: r-- (read allowed)                      │
│                                                                │
│     DECISION: ALLOW                                            │
│                                                                │
│  5. Create file descriptor, add to process's fd table          │
│                                                                │
│  6. Return fd to user space                                    │
└────────────────────────────────────────────────────────────────┘

Key enforcement points:

Path traversal: Each directory component requires execute permission to traverse
Final access check: The object's permissions are checked against the request
File descriptor creation: Success creates a runtime capability
Subsequent operations: Later read()/write() calls check the fd, not the original path

Why checking happens at open(), not read():

This design is critical. Permission checks happen when you acquire access (open), not when you use access (read/write). This means:

Permissions are checked once, reducing overhead
Permissions can change after open() without affecting existing file descriptors
A file can be deleted while still being read (common Unix behavior)

The file descriptor becomes a capability—proof that you passed the access check. Holding a valid fd demonstrates permission.

The TOCTOU Problem

Time-of-Check to Time-of-Use (TOCTOU) is a race condition vulnerability. If a program checks permissions on a file, then separately opens it, an attacker might swap the file between check and open. Solution: Don't separate checking and use—let the kernel check during the open() call itself, then use the returned fd. Never check permissions in user space then assume they'll hold.

Types of Access Rights for Files

Different operations on files require different permissions. Understanding what each access right permits—and what it doesn't—is essential for configuring file protection correctly.

Common File Access Rights
Right	Symbol	For Files	For Directories
Read	r	View file contents, copy file	List directory contents (ls)
Write	w	Modify file contents, truncate	Create/delete files in directory, rename
Execute	x	Run as program/script	Traverse (cd into) the directory
Append	a*	Add to end only, no overwrite	Typically combined with write
Delete	d*	Remove the file	Usually requires directory write
Change permissions	—	Modify protection settings	Owner or superuser only
Change ownership	—	Transfer to another user	Superuser only (usually)

Note: Append and delete are explicit rights in some systems (like AFS) but implied by read/write in others (like basic Unix).

The subtleties of directory permissions:

Directory permissions are often misunderstood:

Read on directory (r): You can list what's in the directory, but not necessarily access the files inside
Execute on directory (x): You can traverse into the directory and access files (if you know their names)
Write on directory (w): You can add or remove directory entries—this is how you delete files!

Critical insight: To delete a file, you don't need write permission on the file—you need write permission on the directory containing it. The file's permissions are irrelevant to deletion.

With Directory x (execute only)

•Can cd into the directory
•Can access files inside if you know their names
•Cannot list contents (ls fails)
•Useful for 'secret URL' patterns

With Directory r (read only)

•Can list contents (ls works)
•Cannot cd into directory
•Cannot access files inside
•Can see names but not contents

The Sticky Bit for Directories

In directories with write permission for multiple users (like /tmp), anyone could delete anyone's files. The sticky bit (t) restricts deletion: you can only remove files you own, even if you have directory write access. This is why /tmp has permissions drwxrwxrwt—the 't' protects users from each other while allowing everybody to create temporary files.

Access Control in Practice

Let's examine how access control manifests in real operating system operations. These examples illustrate the principles we've discussed.

permission_examples.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
# Examining file permissions on Linux
 
$ ls -la /etc/passwd /etc/shadow /home/alice
-rw-r--r-- 1 root   root   2847 Jan 15 10:23 /etc/passwd
-rw-r----- 1 root   shadow 1501 Jan 15 10:23 /etc/shadow
drwxr-x--- 15 alice alice  4096 Jan 16 09:45 /home/alice
 
# /etc/passwd: world-readable (contains usernames, not passwords)
# Owner: root can read/write
# Group: root group can read
# Others: everyone can read
 
# /etc/shadow: contains hashed passwords, restricted access
# Owner: root can read/write
# Group: shadow group can read (for PAM authentication services)
# Others: NO ACCESS
 
# /home/alice: user's home directory
# Owner: alice can read/write/enter
# Group: alice can read/enter (but not write)
# Others: CANNOT even list or enter
 
# What happens when bob tries to access alice's files?
$ whoami
bob
$ cat /home/alice/document.txt
cat: /home/alice/document.txt: Permission denied
# Bob cannot even traverse into /home/alice
 
# But alice can grant access:
# alice runs: chmod 750 /home/alice
#            chmod 644 /home/alice/public.txt
$ ls -l /home/alice/public.txt
-rw-r--r-- 1 alice alice 1024 Jan 16 09:30 public.txt
# Now anyone can read public.txt (if they can traverse to it)

Analyzing the examples:

Defense in depth: /etc/shadow has restricted permissions AND is encrypted—multiple layers of protection.
Path traversal matters: Even if /home/alice/public.txt is world-readable, users without execute permission on /home/alice cannot reach it.
Ownership vs. permissions: Root owns /etc/passwd but deliberately makes it world-readable. Ownership enables control; permissions define policy.
Group flexibility: The shadow group allows authentication services to verify passwords without running as root.

Common Permission Mistakes

chmod 777: Never use this. It makes files world-writable—any user can modify or replace them.

Forgetting directory permissions: Setting a file readable but its parent directory untraversable achieves nothing.

Ignoring group permissions: Leaving group write access on files owned by a shared group can lead to accidental modification.

World-writable directories without sticky bit: Enables file deletion attacks between users.

Summary: Access Control Foundations

We've established the theoretical and practical foundations of file access control. These concepts underpin every protection mechanism we'll explore in subsequent pages.

Key Takeaways

•Access control decides whether a subject (user/process) can perform an operation (read/write/execute) on an object (file/directory).
•Authentication and authorization are distinct — Authentication establishes identity; authorization determines permitted actions.
•Security principles guide design — Least privilege, complete mediation, fail-safe defaults, and others form the foundation of secure systems.
•The access control matrix is the theoretical model; in practice, it's stored as ACLs (with objects) or capabilities (with subjects).
•Enforcement happens at system call boundaries — The kernel is the reference monitor that cannot be bypassed.
•Directory permissions are subtle — Execute enables traversal, read enables listing, and write enables file creation/deletion.

What's next:

With the fundamentals established, we'll examine specific permission models. The next page explores the classic User/Group/World model—Unix's elegant, minimalist approach that uses just 9 bits to express file permissions. This model, despite its age, remains the default protection mechanism on billions of devices worldwide.

Page Complete

You now understand the fundamental concepts of access control: the subject-object-operation model, the principles that guide secure design, how access control matrices are implemented, and where enforcement happens in the kernel. Next, we'll see how Unix implements these concepts with its owner/group/other permission model.