File Protection - Learning Module

Loading content...

0/227

Capabilities: Object References as Access Tokens

A Different Philosophy of Access Control

Every access control mechanism we've examined so far shares a common approach: permissions are stored with the object. The file knows who can access it; the kernel checks this list at access time.

But there's another way. What if instead of objects knowing their permissions, subjects possessed unforgeable tokens that granted access? You don't ask "does Alice have permission to read this file?" but rather "does Alice possess a valid capability for reading this file?"

This is capability-based security—a fundamentally different access control paradigm that influences everything from file descriptors in Unix to modern container isolation and the least-privilege designs in production systems.

What You Will Learn

By the end of this page, you will understand: the conceptual difference between ACLs and capabilities, how capabilities represent the row-major view of the access matrix, why file descriptors are capabilities (partially), capability properties—unforgeability and confinement, how Linux capabilities divide root privileges, and the tradeoffs between capability and ACL models.

What Is a Capability?

A capability is an unforgeable token that both identifies an object and grants specific rights to that object. Think of it as a key that simultaneously specifies which lock it opens and what actions it permits.

The Three Essential Properties of Capabilities

•Designation — A capability identifies a specific object. Holding the capability means you can reference the object. There's no need for a separate naming step—the capability IS the name.
•Authority — A capability specifies what operations are permitted on the object. Different capabilities for the same object can grant different rights (read-only vs read-write, etc.).
•Unforgeability — Capabilities cannot be created out of thin air. They must be obtained through legitimate means—created by the system, inherited, or explicitly transferred by someone who holds them. You cannot forge a capability to an object you don't have access to.

Real-world analogy:

Consider a concert ticket. It:

Designates a specific event (this concert, this seat)
Authorizes entry and a place to sit
Is unforgeable (barcodes, holograms, secure printing)

You don't show ID at the door and ask "do I have permission to enter?" You present the ticket—a capability that proves you have the right.

Contrast with ACLs:

ACLs vs Capabilities: Fundamental Contrasts
Aspect	ACL Model	Capability Model
Where permissions live	With the object	With the subject
Access matrix view	Column-major (per object)	Row-major (per subject)
"Can Alice read X?"	Check X's ACL for Alice	Check Alice's capabilities for X
"Who can access X?"	Easy (read X's ACL)	Hard (check all subjects)
"What can Alice access?"	Hard (check all objects)	Easy (list Alice's capabilities)
Granting access	Modify object's permission list	Transfer a capability to subject
Revoking access	Modify object's permission list	Complex (must revoke capability)
Name implies access?	No (name and check are separate)	Yes (capability IS the name)

Designation + Authority Combined

In the ACL model, you first NAME an object (pathname) and then ACCESS is checked separately. This separation enables confused deputy attacks. In capability systems, naming and authority are unified: you cannot even refer to an object without holding a capability that grants access. No capability, no reference.

Capabilities as the Row View of the Access Matrix

Recall the access control matrix from Page 1. It shows subjects (rows) and objects (columns), with permissions in cells. There are two ways to implement this matrix:

Column-major (ACLs): Store each column with its object. The file /home/alice/secret.txt stores a list: [(alice, rw), (bob, r), (auditors, r)].

Row-major (Capabilities): Store each row with its subject. Alice holds a list of capabilities: [(secret.txt, rw), (project/, rx), (/bin/ls, x)].

matrix_views.txt

Access Matrix Views

                    Access Control Matrix
                    ═══════════════════════
                 
                    Objects →
                    ┌─────────────┬─────────────┬─────────────┐
Subjects  │ /etc/passwd │ alice/secret│ /var/log    │
   ↓      ├─────────────┼─────────────┼─────────────┤
   alice  │     r       │     rw      │     -       │
   bob    │     r       │     r       │     r       │
   root   │     rw      │     rw      │     rw      │
          └─────────────┴─────────────┴─────────────┘
 
Column-Major (ACL) Storage:
───────────────────────────
/etc/passwd stores:      [(alice,r), (bob,r), (root,rw)]
alice/secret stores:     [(alice,rw), (bob,r), (root,rw)]
/var/log stores:         [(bob,r), (root,rw)]
 
"Each OBJECT knows its permitted SUBJECTS"
 
Row-Major (Capability) Storage:
───────────────────────────────
alice holds caps:        [(/etc/passwd,r), (alice/secret,rw)]
bob holds caps:          [(/etc/passwd,r), (alice/secret,r), (/var/log,r)]
root holds caps:         [(/etc/passwd,rw), (alice/secret,rw), (/var/log,rw)]
 
"Each SUBJECT knows its accessible OBJECTS"

Implications of each view:

ACLs make it easy to answer: "Who can access this file?" (Just read the ACL.) But hard to answer: "What can this user access?" (Must scan all ACLs.)

Capabilities invert this: easy to answer "What can this user do?" (List their capabilities.) But hard to answer: "Who has access to this file?" (Must check all users' capability lists.)

Why this matters:

Security audits and access reviews often need both questions answered. Pure ACL systems struggle with per-user audits; pure capability systems struggle with per-object audits. Most real systems are hybrids.

The Revocation Problem

ACL revocation is simple: edit the ACL. Capability revocation is hard: you must somehow revoke or invalidate a token that the subject already possesses. Solutions include: (1) indirection through a revocable reference, (2) expiring capabilities, (3) capability lists maintained by the kernel (not truly held by subjects). This is why hybrid approaches dominate.

File Descriptors: Capabilities in Unix

If you've programmed in C or any Unix-like environment, you've already used capabilities. File descriptors are capabilities—or at least, they embody capability principles.

When you call open("/path/to/file", O_RDONLY), the kernel:

Checks if you have permission (ACL check on the pathname)
If allowed, creates an unforgeable token (the file descriptor)
Returns this token to your process

Subsequent read() and write() calls don't re-check the pathname's permissions. They use the file descriptor—a capability that proves you passed the access check.

fd_capability.c
C
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
#include <fcntl.h>
#include <unistd.h>
 
int main() {
    // ACL check happens here — the ambient authority check
    int fd = open("/etc/passwd", O_RDONLY);
    if (fd < 0) {
        return 1;  // Permission denied or file not found
    }
    
    // fd is now a capability: unforgeable proof of read access
    
    char buffer[1024];
    
    // These calls use capability only — no ACL check
    ssize_t bytes = read(fd, buffer, sizeof(buffer));
    
    // Even if someone changes /etc/passwd permissions right now,
    // this process keeps its access through the fd.
    
    // fd can be inherited by child processes (capability passing)
    if (fork() == 0) {
        // Child also has the fd capability
        read(fd, buffer, sizeof(buffer));  // Works!
    }
    
    // fd can be passed to unrelated processes via Unix sockets
    // (SCM_RIGHTS mechanism) — capability transfer
    
    close(fd);  // Revoke the capability for this process
    return 0;
}

File descriptor as capability checklist:

✅ Designates an object — The fd refers to a specific open file (the kernel maintains the mapping) ✅ Grants authority — The fd specifies read, write, or both (depending on open flags) ✅ Unforgeable — Processes cannot create arbitrary fds; the kernel assigns them ✅ Transferable — Can be inherited (fork) or sent (SCM_RIGHTS)

But Unix isn't a pure capability system:

Where Unix Deviates from Pure Capability Model

•Ambient authority — Processes can call open() with any pathname. The capability (fd) is obtained through an ACL check, not by receiving a capability from another process.
•UID-based checks for open() — The open() call uses the process's UID to check ACLs. This is identity-based, not capability-based.
•Global namespace (pathnames) — Any process can name any file via pathname. In pure capability systems, you can only name objects you have capabilities for.
•No confinement by default — A Unix process can open network connections, access /tmp, read world-readable files—all without receiving capabilities. Pure capability systems start with no authority.

The Confused Deputy Problem

Because Unix separates naming (pathname) from authority (UID check), a privileged program can be tricked into accessing the wrong file. Example: A setuid compiler accepts an output path from the user. If the user specifies /etc/passwd, the compiler—running as root—overwrites it. The compiler (the 'deputy') is 'confused' about whose authority to use. Pure capability systems avoid this: the user would have to pass a capability to /etc/passwd, which they don't have.

Linux Capabilities: Dividing Root Privilege

Confusingly, Linux has a feature called "capabilities" that is not the same as capability-based security. Linux capabilities divide the monolithic root privilege into discrete, assignable units.

Traditionally, you're either root (UID 0, can do anything) or you're not. This violates least privilege—a program needing only to bind port 80 gets full system access if run as root.

Linux capabilities split root into ~40 discrete privileges:

Common Linux Capabilities
Capability	Grants Permission To	Example Use Case
`CAP_NET_BIND_SERVICE`	Bind to ports < 1024	Web server on port 80
`CAP_NET_ADMIN`	Configure network interfaces	VPN software, network tools
`CAP_NET_RAW`	Use raw sockets	Ping, network diagnostics
`CAP_SYS_ADMIN`	Many admin operations	Mount, sethostname, etc.
`CAP_DAC_OVERRIDE`	Bypass file permission checks	Backup software
`CAP_CHOWN`	Change file ownership arbitrarily	Archive extraction
`CAP_KILL`	Send signals to any process	Process managers
`CAP_SETUID`	Set UID arbitrarily	Login services, su/sudo
`CAP_SYS_PTRACE`	Trace any process (debugging)	Debuggers, strace
`CAP_SYS_TIME`	Set system time	NTP daemon

linux_caps.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
# View capabilities of a running process
$ cat /proc/$$/status | grep Cap
CapInh: 0000000000000000    # Inheritable (passed to children)
CapPrm: 0000000000000000    # Permitted (max available)
CapEff: 0000000000000000    # Effective (currently active)
CapBnd: 000001ffffffffff    # Bounding set (absolute limit)
CapAmb: 0000000000000000    # Ambient (inherited across exec)
 
# Decode capability bits
$ capsh --decode=000001ffffffffff
0x000001ffffffffff=cap_chown,cap_dac_override,...
 
# View capabilities of a file (file capabilities)
$ getcap /usr/bin/ping
/usr/bin/ping cap_net_raw=ep
 
# e = effective (use when executed)
# p = permitted (allowed to use)
# i = inheritable (passed to child programs)
 
# Set file capabilities (requires CAP_SETFCAP)
$ sudo setcap cap_net_bind_service=+ep /usr/bin/my-server
 
# Now my-server can bind to port 80 without running as root!
 
# Run a program with specific capabilities only
$ capsh --drop=all --caps="cap_net_bind_service+eip" -- -c "/my-server"
 
# List all defined capabilities
$ capsh --print | grep "Current IAB"

Capability sets:

Each process has multiple capability sets:

Permitted — The ceiling. Capabilities the process MAY use (but aren't necessarily active).
Effective — Currently active. These are checked for privileged operations.
Inheritable — Can be passed to programs run via exec().
Bounding — Hard limit. Caps not in bounding set can never be acquired.
Ambient — Preserved across exec() to non-setuid programs (newer, rarely used).

Replacing setuid with File Capabilities

Modern Linux can eliminate many setuid programs:

Before: ping is setuid root (gains full root on execution) After: ping has cap_net_raw=ep (gains only raw socket capability)

This drastically reduces the attack surface. A vulnerability in ping no longer grants full root—only raw socket access.

Capability Discipline: Least Privilege by Design

Pure capability systems enforce least privilege by construction. A process starts with no capabilities and must receive them from a parent or be explicitly granted them. This is radically different from Unix's ambient authority where any process can attempt to open any file.

The principle of capability discipline:

Key Capability Discipline Rules

•No ambient authority — Processes cannot spontaneously gain access to objects. All access derives from explicitly granted capabilities.
•Delegation, not escalation — You can pass a capability you hold to another process. You cannot create capabilities you don't have.
•Attenuation — When passing a capability, you can restrict it further (e.g., pass a read-write cap as read-only). You cannot amplify.
•Confinement — A process with no capabilities for network or filesystem has no way to exfiltrate data, regardless of what code it runs.
•Explicit communication — Resources flow through explicit capability passing, making security policies visible in code structure.

capability_discipline.txt

Pseudocode

// Traditional Unix: ambient authority
function processUserInput(input: string) {
    // This process can access ANYTHING its UID allows
    // The compiler function might write anywhere!
    let output = compile(input);
    let path = getUserSpecifiedPath();  // User controls this
    writeFile(path, output);  // DANGER: confused deputy
}
 
// Capability discipline: explicit authority
function processUserInput(input: string, outputCapability: WriteCapability) {
    // This process can ONLY write to what it has a capability for
    let output = compile(input);
    // outputCapability was provided by caller - can only write there
    outputCapability.write(output);  // SAFE: uses provided capability
    
    // Even if malicious, cannot write elsewhere - no capability!
    // writeFile("/etc/passwd", "hacked");  // Would need capability!
}
 
// The caller provides exactly the capabilities needed:
let sandboxedCompiler = startProcess(compileCode);
let outputCap = createWriteCapability(tempDir);  // Write to temp only
sandboxedCompiler.invoke(untrustedCode, outputCap);
// compileCode cannot access network, cannot read $HOME, etc.

Sandboxing through capability restriction:

Modern security measures like seccomp, Capsicum (FreeBSD), and Landlock (Linux) implement capability-style confinement:

seccomp-bpf — Restrict which syscalls a process can make
Capsicum — FreeBSD's capability mode; process loses ambient authority
Landlock — Linux's filesystem sandboxing; process voluntarily restricts file access
Pledge/Unveil — OpenBSD's syscall and path restriction

These systems don't use capabilities directly but achieve similar confinement by removing ambient authority.

Containers Use Capability Ideas

Docker and container runtimes drop Linux capabilities by default. A container might run as 'root' (UID 0) but without CAP_SYS_ADMIN, CAP_NET_ADMIN, etc. This is capability-based thinking applied to containerization—minimize privilege even for processes that appear privileged.

Capability-Based Systems in Practice

While mainstream OSes aren't pure capability systems, capability ideas appear throughout computing, and several research/specialized systems fully embrace the model.

Capability Systems and Influences
System	Type	Capability Aspect
seL4	Microkernel	All system resources accessed via capabilities; formally verified
Capsicum (FreeBSD)	Capability mode	Sandbox mode with no global namespace access
Google Fuchsia	Operating system	Objects accessed via capabilities (handles)
E Language	Programming language	Object-capabilities; unforgeable object references
WebAssembly (WASI)	Runtime	Host-provided capabilities for syscall access
File Descriptors	Unix mechanism	Unforgeable references post-open()
iOS/Android Permissions	Mobile OS	Apps declare/granted capabilities (camera, location, etc.)
CloudABI	ABI sandbox	POSIX variant using capabilities; no ambient authority

Capsicum: A deep example:

FreeBSD's Capsicum allows processes to enter "capability mode" where:

Global namespaces (/path/to/file) become inaccessible
Only pre-opened file descriptors (capabilities) can be used
New descriptors can only be created from existing ones (openat() relative to fd)
This enables true sandboxing for components like compression libraries, parsers, etc.

capsicum.c
C
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
// Capsicum sandboxing example (FreeBSD)
#include <sys/capsicum.h>
 
int main(int argc, char *argv[]) {
    // Open necessary files BEFORE entering capability mode
    int input_fd = open(argv[1], O_RDONLY);
    int output_fd = open(argv[2], O_WRONLY | O_CREAT, 0644);
    
    // Limit rights on descriptors (attenuation)
    cap_rights_t rights;
    cap_rights_init(&rights, CAP_READ);  // input: read-only
    cap_rights_limit(input_fd, &rights);
    
    cap_rights_init(&rights, CAP_WRITE); // output: write-only
    cap_rights_limit(output_fd, &rights);
    
    // Enter capability mode - lose all ambient authority!
    cap_enter();
    
    // Now in sandbox:
    // - open("/etc/passwd", ...) → FAILS (no global namespace)
    // - socket(), connect() → FAIL (no network capability)
    // - read(input_fd, ...) → WORKS (have this capability)
    // - write(output_fd, ...) → WORKS (have this capability)
    
    // Even if this code has a vulnerability, attacker can only:
    // - Read from input_fd
    // - Write to output_fd
    // Cannot access network, other files, etc.
    
    process_data(input_fd, output_fd);  // Sandboxed processing
    
    return 0;
}

Modern Security Follows Capability Principles

Even if not using formal capability systems, modern security practice applies the same ideas: explicit grants instead of ambient authority, minimal privilege, sandboxing by default. Understanding capabilities helps you design secure systems even in traditional environments.

Capabilities vs ACLs: Tradeoffs and Choosing

Neither model is universally superior. Each has strengths suited to different security requirements:

ACL Strengths

•Revocation is simple — Edit the ACL; next access denied
•Audit per-object — Easy to see who can access a file
•Centralized policy — Admins control permissions on objects
•Familiar model — Widely understood, well-tooled
•Persistent — ACLs survive reboots automatically

Capability Strengths

•Least privilege by default — Start with nothing, grant explicitly
•Audit per-subject — Easy to see what a process can access
•Delegation built-in — Passing capabilities is natural
•Prevents confused deputy — Authority is explicit in code
•Sandboxing — True confinement through capability restriction

When to prefer each:

ACLs work well for:

System administration ("who can access this file?")
Persistent resources (files, databases)
Centralized policy management
Situations where revocation is common
User-facing permission interfaces

Capabilities work well for:

Component isolation (sandboxing)
Untrusted code execution
Situations where delegation is the primary access pattern
Fine-grained privilege (per-operation, per-resource)
Programmatic security (permissions in code)

Real Systems Are Hybrids

Unix uses ACLs for acquiring file access (open() checks ACL) but capabilities for using it (fd is a capability). Modern systems layer capability-based sandboxing (seccomp, Landlock) over ACL-based filesystems. Pure models are conceptually clean but hybrid approaches are practical.

Applying Capability Thinking in Practice

Even without a pure capability OS, you can apply capability principles to improve security:

Practical Capability Design Patterns

•Pass resources, not ambient authority — Functions should receive file handles, not paths. processFile(fd) is safer than processFile("/path") because the caller controls what resource is accessed.
•Open early, drop late — Open all needed resources at startup, then drop privileges (with seccomp, pledge, etc.). This mimics capability mode entry.
•Use file descriptors as capabilities — Pass fds between processes (via inheritance or SCM_RIGHTS) instead of pathnames. The recipient can only use the fd, not access arbitrary files.
•Apply Linux capabilities to binaries — Use setcap to grant specific privileges instead of making programs setuid root.
•Sandbox untrusted components — Use seccomp, Landlock, or containers to confine parsers, decompressors, and other exploit-prone code.
•Design APIs around capabilities — If writing a library, have callers pass resources explicitly. Don't access global resources based on configuration files or environment variables.

capability_pattern.c
C
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
// BAD: Ambient authority pattern
void processUserData(const char* username) {
    // Function reaches into filesystem based on username
    char path[256];
    snprintf(path, sizeof(path), "/data/users/%s/profile.json", username);
    int fd = open(path, O_RDONLY);  // What if username is "../../../etc/passwd"?
    // ... vulnerable to path traversal
}
 
// GOOD: Capability pattern
void processUserData(int profile_fd) {
    // Caller provides the fd; this function cannot access other files
    // Even if logic is buggy, cannot escape to other resources
    char buffer[4096];
    read(profile_fd, buffer, sizeof(buffer));
    // ...
}
 
// Caller opens the file with proper validation:
int main() {
    // Validate username, construct path safely
    int fd = openat(users_dir_fd, validated_username, O_RDONLY);
    processUserData(fd);  // Pass capability, not name
    close(fd);
}

The openat() Pattern

The *at() family of syscalls (openat, mkdirat, readlinkat, etc.) enable capability-style programming. Instead of using the global namespace, you open paths relative to a directory fd. This limits which directories a function can access to those you explicitly provide.

Summary: Capabilities

Key Takeaways

•Capabilities combine naming and authority — A capability is an unforgeable token that both identifies an object and grants access rights.
•Row-major vs column-major — Capabilities store permissions with subjects (what can this process access?); ACLs store them with objects (who can access this file?).
•File descriptors are capabilities — After open() succeeds, the fd is an unforgeable token for subsequent access without re-checking the path.
•Linux 'capabilities' are privilege divisions — Splitting root into CAP_NET_BIND_SERVICE, CAP_SYS_ADMIN, etc. for finer-grained privilege assignment.
•Capability discipline enables confinement — No ambient authority means untrusted code truly cannot access unintended resources.
•Revocation is hard in pure capability systems — ACLs revoke by editing; capabilities require invalidating distributed tokens.
•Hybrid approaches dominate — Real systems use ACLs for persistent policy and capability-like mechanisms for runtime access.
•Apply capability thinking — Pass resources not paths, open early/drop privileges, sandbox untrusted code.

What's next:

The final page of this module explores Permission Models—bringing together ACLs, capabilities, and extensions like Role-Based Access Control (RBAC), Mandatory Access Control (MAC), and attribute-based policies. We'll see how these models compose to form the layered security frameworks of modern operating systems.

Page Complete

You now understand capability-based security—its theoretical basis, its manifestation in file descriptors, Linux capabilities, and modern sandboxing, and how to apply capability thinking even in non-capability systems. This perspective is essential for secure system design.