Operating SystemsProtection Mechanisms

Protection Goals

LevelIntermediate

Duration60 mins

TopicProtection Mechanisms

5 / 5

Authorization

Deciding What You Can Do

Authentication establishes who you are. But knowing your identity is just the beginning. The critical security decision is: what are you allowed to do? Can you read this file? Can you modify that configuration? Can you execute this command? Can you access this network resource?

Authorization (sometimes called access control) is the process of determining whether a particular identity should be granted access to a particular resource for a particular operation. Every file access, every system call, every network connection involves an authorization decision. The operating system makes millions of these decisions every second.

What You Will Learn

By the end of this page, you will understand authorization as distinct from authentication, learn the core authorization models used in operating systems, appreciate the implementation of permission checking, understand the principle of least privilege, and recognize how authorization policies are expressed and enforced.

Authorization Fundamentals

Authorization requires three pieces of information:

Subject (or Principal): The entity requesting access—typically a user or process
Object (or Resource): The thing being accessed—files, devices, memory, services
Operation: The action being requested—read, write, execute, delete, etc.

An authorization decision evaluates: 'Should this subject be permitted to perform this operation on this object?' The answer comes from a policy that maps (subject, object, operation) tuples to permit/deny decisions.

Authorization vs. Authentication:

These concepts are distinct but related:

Authentication: Verifying 'you are alice'
Authorization: Determining 'alice may read /home/alice/file.txt'

Authentication precedes authorization. First, verify identity; then, consult authorization policy for that identity.

Core Authorization Concepts
Concept	Definition	Example in Unix
Subject	Entity requesting access	User (UID), Process, Group (GID)
Object	Resource being accessed	File, directory, device, socket
Operation	Action being requested	Read, write, execute, chmod
Permission	Right to perform operation	rwx bits, ACL entries
Policy	Rules determining access	File mode bits, SELinux policy
Reference Monitor	Enforces policy on every access	Kernel permission checks, LSM

The Reference Monitor Concept:

The reference monitor is a security component that mediates all access between subjects and objects. It is:

Always invoked: Cannot be bypassed
Tamper-proof: Cannot be modified
Verifiable: Small enough to analyze

In operating systems, the kernel implements the reference monitor. Every system call that accesses resources passes through kernel authorization checks. The kernel's privileged position makes it the only component that can reliably enforce authorization.

Fail-Safe Defaults

A fundamental authorization principle: access should be denied by default unless explicitly granted. If the authorization system fails or cannot make a determination, denying access is safer than permitting it. This 'default deny' approach ensures that authorization failures create unavailability (which is often recoverable) rather than security breaches (which may not be).

Discretionary Access Control (DAC)

Discretionary Access Control (DAC) is the authorization model where resource owners determine who can access their resources. The 'discretionary' aspect means owners have discretion—they set permissions according to their judgment.

Traditional Unix Permissions:

The classic Unix permission model is DAC. Every file has:

An owner (user) who can set permissions
A group that may have different permissions
Permissions for others (everyone else)

For each category, three bits control: read (r), write (w), execute (x). This creates the familiar 'rwxrwxrwx' notation seen in ls -l output.

Unix Permission Bits
Permission	On Files	On Directories	Octal Value
Read (r)	View file contents	List directory contents	4
Write (w)	Modify file contents	Create/delete files in directory	2
Execute (x)	Run as program	Enter directory (cd)	1
SetUID (s)	Run as owner	N/A	4000
SetGID (s)	Run as group	New files inherit group	2000
Sticky (t)	N/A	Only owner can delete their files	1000

Unix Permission Checking
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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
#include <sys/stat.h>
#include <unistd.h>
#include <stdio.h>
 
/**
 * Demonstrates how Unix permission checking works.
 * This reflects the logic inside the kernel.
 */
 
/* Permission bits */
#define S_IRWXU 0700  /* rwx for owner */
#define S_IRWXG 0070  /* rwx for group */
#define S_IRWXO 0007  /* rwx for others */
 
/**
 * Check if process with given credentials can access file.
 * Simplified version of kernel access check.
 * 
 * Real check considers:
 * - Capabilities (CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH)
 * - Supplementary groups
 * - ACLs if present
 */
int check_permission(struct stat *st, uid_t uid, gid_t gid, 
                     int requested_mode) {
    mode_t mode = st->st_mode;
    mode_t granted;
    
    /* Root (UID 0) bypasses most checks */
    if (uid == 0) {
        /* For execute: at least one execute bit must be set */
        if (requested_mode & X_OK) {
            if (!(mode & (S_IXUSR | S_IXGRP | S_IXOTH))) {
                return -1;  /* No execute permission */
            }
        }
        return 0;  /* Root can do everything else */
    }
    
    /* Determine which permission bits apply */
    if (uid == st->st_uid) {
        /* We are the owner - use owner bits */
        granted = (mode >> 6) & 7;
    } else if (gid == st->st_gid) {
        /* We are in the group - use group bits */
        /* Note: Real check also verifies supplementary groups */
        granted = (mode >> 3) & 7;
    } else {
        /* We are 'other' */
        granted = mode & 7;
    }
    
    /* Check if requested permissions are subset of granted */
    if (requested_mode & R_OK) {
        if (!(granted & 4)) return -1;  /* Read not permitted */
    }
    if (requested_mode & W_OK) {
        if (!(granted & 2)) return -1;  /* Write not permitted */
    }
    if (requested_mode & X_OK) {
        if (!(granted & 1)) return -1;  /* Execute not permitted */
    }
    
    return 0;  /* Access permitted */
}
 
/* 
 * Special permissions: SetUID/SetGID
 * When executable with setuid is run, process gets owner's UID
 */
void explain_setuid() {
    /*
     * /usr/bin/passwd has setuid bit:
     * -rwsr-xr-x 1 root root 54256 Jan 10 08:00 /usr/bin/passwd
     *    ^-- 's' means setuid on owner execute
     * 
     * When alice runs passwd:
     * - Real UID: alice (1000)
     * - Effective UID: root (0)  <-- from setuid
     * 
     * This allows passwd to update /etc/shadow (owned by root)
     * even though alice cannot directly write /etc/shadow.
     */
}
 
/* Check file permissions from user space */
int main() {
    /* access() checks using real UID/GID */
    if (access("/etc/shadow", R_OK) == 0) {
        printf("You can read /etc/shadow\n");
    } else {
        printf("Cannot read /etc/shadow: %m\n");
    }
    
    /* euidaccess() or eaccess() uses effective UID/GID */
    /* This matters for setuid programs */
    
    return 0;
}

The Confused Deputy Problem

DAC has a fundamental weakness: the 'confused deputy' vulnerability. If a privileged program (deputy) can be tricked into acting on behalf of a less-privileged user, it may perform unauthorized operations using its own privileges. For example, if a setuid program opens a file path provided by user input, an attacker might symlink that path to a protected file. The program, running as root, happily accesses the protected file on the attacker's behalf.

Mandatory Access Control (MAC)

Mandatory Access Control (MAC) takes authorization decisions away from resource owners and centralizes them in system policy. Users cannot change security labels or bypass MAC restrictions, even on resources they 'own.'

Why MAC Exists:

DAC fails in environments requiring strong security guarantees. If users can set any permissions on their files, nothing prevents them from accidentally (or intentionally) making sensitive data accessible. Military and government systems required an authorization model where policy is mandatory, not discretionary.

Labels and Security Levels:

In MAC systems, every subject (process) and object (file) has a security label. Operations are permitted only when labels satisfy the security policy. The classic model uses hierarchical labels (Top Secret > Secret > Confidential > Unclassified) plus compartments (need-to-know categories).

MAC vs DAC Comparison
Aspect	DAC	MAC
Who sets policy	Resource owner	System administrator
User can change permissions	Yes	No (unless admin grants)
Root can bypass	Yes	Not necessarily
Focus	User convenience	System-wide security
Typical use	General purpose systems	High-security environments
Complexity	Simple	Complex policies
Examples	Unix permissions, Windows ACLs	SELinux, AppArmor, MLS

SELinux:

Security-Enhanced Linux (SELinux) is the most prominent MAC implementation for Linux. Developed by the NSA, it adds mandatory access control to the standard Linux DAC. Every process runs in a domain, every file has a type, and policy rules determine which domains can access which types.

Type Enforcement:

SELinux primarily uses Type Enforcement (TE). Policy rules have the form:

allow source_domain target_type:class permissions;

For example: allow httpd_t httpd_sys_content_t:file read;

This permits the Apache web server (httpd_t domain) to read files labeled httpd_sys_content_t. Apache cannot read files with other labels, even if Unix permissions would allow it.

SELinux in Action
Bash
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
41
42
43
44
45
46
47
48
# SELinux adds security labels to all subjects and objects
# Labels have format: user:role:type:level
 
# View file security context
$ ls -Z /var/www/html/index.html
-rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0 index.html
                                        ^^^^^^^^^^^^^^^^^^^^^^^^^
                                        SELinux type
 
# View process security context  
$ ps -eZ | grep httpd
system_u:system_r:httpd_t:s0     1234 ?        00:00:05 httpd
                 ^^^^^^^^
                 Process type/domain
 
# Type Enforcement: httpd_t can read httpd_sys_content_t
# but NOT other types
 
# Create file with wrong label
$ echo "test" > /var/www/html/test.html
$ ls -Z /var/www/html/test.html
-rw-r--r--. root root unconfined_u:object_r:admin_home_t:s0 test.html
 
# Apache cannot read this file (wrong type)!
# Access denied even though Unix permissions allow it
 
# Check for SELinux denials in audit log
$ ausearch -m AVC -ts recent
type=AVC msg=audit(...): avc: denied { read } for pid=1234 
  comm="httpd" name="test.html" 
  scontext=system_u:system_r:httpd_t:s0 
  tcontext=unconfined_u:object_r:admin_home_t:s0 
  tclass=file permissive=0
 
# Fix the label
$ restorecon -v /var/www/html/test.html
# Or manually:
$ chcon -t httpd_sys_content_t /var/www/html/test.html
 
# Now Apache can read it
 
# Key SELinux commands:
getenforce          # Show current mode
setenforce 0|1      # Set permissive (0) or enforcing (1)
sesearch            # Query loaded policy
seinfo              # Show policy statistics  
audit2allow         # Generate policy from denials
sepolicy            # Analyze installed policies

Defense Against Compromised Software

MAC's primary value is confining compromised applications. If an attacker exploits Apache, they're trapped in the httpd_t domain. They cannot read /etc/shadow (shadow_t type), cannot write to system binaries (/bin = bin_t), cannot access other users' files. MAC limits the blast radius of security vulnerabilities.

Role-Based Access Control (RBAC)

Role-Based Access Control (RBAC) introduces an abstraction layer between users and permissions. Instead of directly assigning permissions to users, permissions are assigned to roles, and users are assigned to roles. This simplifies administration in large organizations.

The RBAC Model:

Users: Individual identities (people, service accounts)
Roles: Job functions (admin, operator, auditor, developer)
Permissions: Rights to perform operations on objects
Sessions: Active role activations by users

A user may be assigned multiple roles. During a session, a user can activate a subset of their roles. Permissions for a session are the union of permissions from active roles.

Why RBAC?

Consider an organization with 10,000 users and 100,000 files. With DAC, managing access requires potentially 10,000 × 100,000 individual permission entries. With RBAC, define 50 roles, assign permissions to roles, assign users to roles. Now you manage 50 × 100,000 role-permission assignments plus 10,000 × 50 user-role assignments—dramatically simpler.

RBAC Implementation in Operating Systems
System	RBAC Feature	How It Works
Linux (sudo)	Sudoers roles	Groups in sudoers grant command execution rights
SELinux	SELinux roles	Roles determine available domains for users
Solaris RBAC	Rights profiles	Profiles bundle authorizations and commands
Windows	Built-in groups	Administrators, Users, Power Users, etc.
Windows	Group Policy	Assign rights via security groups
FreeBSD	MAC Framework	Biba, MLS labels with role hierarchies

RBAC with sudoers
Bash
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
41
42
43
44
45
46
47
48
49
50
51
# /etc/sudoers - RBAC-style role definitions
 
# Define command aliases (permission bundles)
Cmnd_Alias DATABASE = /usr/bin/mysql, /usr/bin/mysqldump, \
                      /usr/bin/pg_dump, /usr/bin/psql
 
Cmnd_Alias NETWORKING = /sbin/ifconfig, /sbin/ip, /sbin/iptables, \
                        /sbin/route, /usr/bin/ss
 
Cmnd_Alias SERVICES = /bin/systemctl start *, \
                      /bin/systemctl stop *, \
                      /bin/systemctl restart *, \
                      /bin/systemctl status *
 
Cmnd_Alias READONLY = /usr/bin/cat, /usr/bin/less, /usr/bin/head, \
                      /usr/bin/tail, /bin/ls
 
Cmnd_Alias DANGEROUS = /bin/rm, /bin/dd, /sbin/fdisk, /sbin/mkfs.*
 
# Define roles (groups) and their permissions
 
# Database administrators - full database access
%dba_role ALL=(ALL) DATABASE
 
# Network operators - network configuration
%netops_role ALL=(ALL) NETWORKING
 
# Service operators - start/stop services
%service_ops ALL=(ALL) SERVICES
 
# Security auditors - read-only access to logs
%auditor_role ALL=(ALL) NOPASSWD: READONLY
 
# Junior admins - services and networking, no dangerous commands
%junior_admin ALL=(ALL) SERVICES, NETWORKING, !DANGEROUS
 
# Senior admins - everything except explicit denials
%senior_admin ALL=(ALL) ALL, !DANGEROUS
 
# Full administrators - everything
%wheel ALL=(ALL) ALL
 
# Role assignment happens via group membership:
# usermod -aG dba_role alice     # Alice gets database admin role
# usermod -aG netops_role bob    # Bob gets network operator role
# usermod -aG auditor_role carol # Carol gets auditor role
 
# Verify effective permissions
$ sudo -l -U alice
User alice may run the following commands:
    (ALL) /usr/bin/mysql, /usr/bin/mysqldump, /usr/bin/pg_dump, /usr/bin/psql

Separation of Duties

RBAC enables separation of duties—ensuring that critical operations require multiple people. For example, policy might specify that 'approver' and 'initiator' roles are mutually exclusive; no one person can both initiate and approve their own transactions. This constraint-based RBAC prevents insider abuse through role engineering.

Capability-Based Security

Capability-based security takes a fundamentally different approach. Instead of checking 'does this subject have permission for this object?', capabilities bundle object reference WITH permission. Possession of a capability IS authorization.

What Is a Capability?

A capability is an unforgeable token that references an object and specifies permitted operations. Key properties:

Combines designation and authority: The capability is both the name and the permission
Unforgeable: Cannot be created or modified except through authorized means
Transferable: Can be passed to other processes (delegation)
Revocable: Can be invalidated (though this is often challenging)

Real-World Analogy:

A physical key to a door is capability-like. Holding the key means you can open the door. You don't need to prove your identity or look up permissions. The key itself is authorization. You can give the key to others (delegation). But if someone copies the key, you can't easily revoke their access without changing the lock.

Capability Advantages

•No confused deputy problem - authority follows capability
•Fine-grained delegation without central administration
•Simpler analysis of authority - follow the capabilities
•Natural fit for object-oriented/component systems
•No ambient authority - must explicitly pass capabilities

Capability Challenges

•Revocation is difficult - all copies must be invalidated
•Auditing is complex - 'who can access X?' requires tracing all capabilities
•Capability leakage - accidentally passing too many rights
•Naming and capability conflation can be awkward
•Less familiar model - harder to reason about for some

Linux Capabilities:

Linux implements a form of capabilities that subdivides root privilege. Instead of all-or-nothing superuser, root's powers are divided into ~40 distinct capabilities:

CAP_NET_ADMIN: Configure network interfaces
CAP_SYS_ADMIN: Many administrative operations
CAP_DAC_OVERRIDE: Bypass file permission checks
CAP_SETUID: Change UID
CAP_KILL: Send signals to any process

Processes can have capabilities without being root, and root processes can drop capabilities to limit damage from compromise.

Linux Capabilities
Bash
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
41
42
43
44
45
46
47
48
49
50
# Linux capabilities subdivide root privilege
 
# View capabilities of a process
$ getpcaps $$
Capabilities for 1234: =
 
# View capabilities of a binary
$ getcap /usr/bin/ping
/usr/bin/ping = cap_net_raw+ep
 
# ping needs CAP_NET_RAW to send ICMP packets
# Before capabilities: ping was setuid root (dangerous)
# With capabilities: ping only has network rights
 
# Set capabilities on binary (requires CAP_SETFCAP)
$ sudo setcap cap_net_bind_service+ep /usr/local/bin/myserver
# Now myserver can bind to ports <1024 without being root
 
# Capability sets in a process:
# Permitted (P): Max capabilities process can acquire
# Effective (E): Currently active capabilities  
# Inheritable (I): Passed to child processes via exec
# Bounding: Upper limit, can only be reduced
 
# Drop capabilities for defense in depth
# /usr/bin/myapp.wrapper:
#!/bin/bash
# Drop all capabilities except what's needed
exec capsh \
    --caps="cap_net_bind_service+eip" \
    --keep=1 \
    --user=nobody \
    --addamb=cap_net_bind_service \
    -- -c "/usr/bin/myapp"
 
# View a running process's capabilities
$ cat /proc/1234/status | grep Cap
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
 
# Decode capability bits
$ capsh --decode=0000003fffffffff
 
# Run command with only specific capabilities
$ sudo capsh --caps='cap_sys_admin+eip cap_dac_read_search+eip' \
    --keep=1 --uid=1000 --gid=1000 \
    -- -c "ls -la /root"

File Descriptors as Capabilities

Unix file descriptors approximate capabilities. An open file descriptor is an unforgeable token granting access to a file. Processes can pass file descriptors over Unix sockets, delegating access. Once a file is opened, the process can access it even if permissions change. This capability-like design, present since early Unix, inspires modern capability-secure systems.

The Principle of Least Privilege

The Principle of Least Privilege is the foundational authorization design principle: every subject should have only the minimum privileges necessary to perform its function. This seems obvious but requires continuous effort to implement.

Why Least Privilege Matters:

Every unnecessary privilege is an opportunity for:

Accidental damage: Mistakes with powerful tools cause more harm
Malicious exploitation: Attackers who compromise a process inherit its privileges
Privilege escalation: Unneeded privileges may be stepping stones to higher privileges

Implementing Least Privilege:

Least privilege isn't a one-time configuration—it's an ongoing discipline:

Grant minimal initial privileges: Start with nothing, add only what's needed
Drop privileges when no longer needed: After privileged operations complete, relinquish extra rights
Separate privileged and unprivileged code: Put privileged operations in small, auditable components
Limit privilege scope: Grant privileges for specific resources, not all resources

Least Privilege Techniques

•Run as unprivileged user — Never run services as root unless absolutely necessary. Create service accounts with minimal rights.
•Drop capabilities — After privileged initialization, drop unneeded Linux capabilities.
•Privilege separation — Split privileged and unprivileged code into separate processes. OpenSSH uses this extensively.
•chroot/containers — Restrict file system view to only required directories.
•seccomp — Limit available system calls to only those needed.
•MAC policies — SELinux/AppArmor confine processes to required resource access.
•Resource limits — ulimit, cgroups prevent processes from consuming excessive resources.
•Time-limited privileges — Sudo timestamps, session timeouts, temporary access.

Privilege Separation in Code
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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
#include <unistd.h>
#include <sys/types.h>
#include <pwd.h>
#include <grp.h>
#include <sys/prctl.h>
#include <linux/seccomp.h>
 
/*
 * Example: Web server privilege separation
 * 
 * Pattern: Start as root to bind port 80,
 * then immediately drop privileges.
 */
 
int main() {
    int listen_fd;
    struct sockaddr_in addr;
    
    /* ===== PRIVILEGED SECTION ===== */
    /* This code runs as root */
    
    /* Create socket and bind to privileged port 80 */
    listen_fd = socket(AF_INET, SOCK_STREAM, 0);
    addr.sin_family = AF_INET;
    addr.sin_port = htons(80);
    addr.sin_addr.s_addr = INADDR_ANY;
    
    if (bind(listen_fd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
        perror("bind");
        return 1;
    }
    
    listen(listen_fd, 128);
    
    /* ===== DROP PRIVILEGES ===== */
    
    /* Get target user info */
    struct passwd *pw = getpwnam("www-data");
    if (pw == NULL) {
        fprintf(stderr, "User www-data not found\n");
        return 1;
    }
    
    /* Change to restricted directory */
    if (chroot("/var/www") != 0) {
        perror("chroot");
        return 1;
    }
    chdir("/");
    
    /* Drop supplementary groups */
    if (setgroups(0, NULL) != 0) {
        perror("setgroups");
        return 1;
    }
    
    /* Drop group privileges (must be before setuid) */
    if (setgid(pw->pw_gid) != 0) {
        perror("setgid");
        return 1;
    }
    
    /* Drop user privileges */
    if (setuid(pw->pw_uid) != 0) {
        perror("setuid");
        return 1;
    }
    
    /* Prevent regaining privileges */
    if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) != 0) {
        perror("prctl");
        /* Non-fatal, but log it */
    }
    
    /* 
     * Optional: Further restrict with seccomp
     * Allow only needed system calls
     */
    
    /* ===== UNPRIVILEGED SECTION ===== */
    /* Now running as www-data, chrooted to /var/www */
    /* Cannot bind new privileged ports */
    /* Cannot access files outside /var/www */
    /* Cannot regain root privileges */
    
    /* Main server loop now runs with minimum privileges */
    while (1) {
        int client_fd = accept(listen_fd, NULL, NULL);
        handle_request(client_fd);  /* Runs unprivileged */
        close(client_fd);
    }
    
    return 0;
}

The Privilege Creep Problem

In practice, privileges tend to accumulate. Users request access for one task and never relinquish it. Service accounts acquire unnecessary rights during debugging and keep them. Regular privilege audits are essential. Ask: 'Does this subject still need these permissions?' Remove what's unnecessary. This requires ongoing effort but dramatically reduces attack surface.

Authorization in Practice

Real-world authorization combines multiple models using layered checks. A typical access decision might involve DAC, then MAC, then application-level controls. Understanding this layered approach helps design comprehensive authorization.

Linux Security Module (LSM) Framework:

Linux uses the LSM framework to implement mandatory access control. LSM inserts hooks at authorization decision points throughout the kernel. When a process attempts an operation, the relevant LSM hook is called, allowing security modules (SELinux, AppArmor, SMACK, etc.) to permit or deny the operation.

Authorization Priority:

In Linux with SELinux:

DAC check first: Traditional Unix permissions
Capability check: Linux capabilities may override DAC
LSM/MAC check: SELinux policy (if enabled)

Access is permitted only if all applicable layers permit it. A single deny from any layer denies access.

Layered Authorization Example
Check	What's Verified	Denial Result
DAC (permissions)	Unix mode bits allow operation	EACCES (Permission denied)
DAC (ownership)	User/group matches owner/group	EACCES
Capabilities	Process has required capability	EPERM (Operation not permitted)
SELinux	Policy allows domain->type access	EACCES (with AVC audit message)
AppArmor	Profile allows path access	EACCES (with audit message)
Namespaces	Resource visible in namespace	ENOENT (No such file)
seccomp	Syscall in allowed set	SIGSYS or EPERM

Tracing Authorization Decisions
Bash
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
41
42
43
44
45
46
47
48
49
50
51
52
53
# Debugging authorization denials
 
# Scenario: Process cannot read a file - why?
 
# Check DAC permissions
$ ls -la /path/to/file.txt
-rw------- 1 alice alice 1234 Jan 15 10:00 file.txt
 
# If running as bob, DAC will deny (no 'other' permissions)
 
# Check if SELinux is involved
$ getenforce
Enforcing
 
# Check SELinux context requirements
$ ls -Z /path/to/file.txt
-rw-------. alice alice unconfined_u:object_r:user_home_t:s0 file.txt
 
$ ps -eZ | grep myprocess
system_u:system_r:httpd_t:s0     myprocess
 
# SELinux may deny httpd_t -> user_home_t access
 
# Check for SELinux denials
$ ausearch -m AVC -ts recent
 
# Check AppArmor (if used instead of SELinux)
$ aa-status
$ dmesg | grep apparmor
 
# Check if capabilities are relevant
$ getpcaps $(pgrep myprocess)
# Does process need CAP_DAC_READ_SEARCH or CAP_DAC_OVERRIDE?
 
# Check namespace isolation
$ ls -la /proc/$(pgrep myprocess)/ns/
# Is the process in a different mount namespace?
 
# Check seccomp filtering
$ grep Seccomp /proc/$(pgrep myprocess)/status
Seccomp:    2
# 2 means SECCOMP_MODE_FILTER (BPF filtering active)
 
# Strace to see actual syscall and errno
$ strace -f -e trace=file myprocess 2>&1 | grep -E "open|access"
openat(AT_FDCWD, "/path/to/file.txt", O_RDONLY) = -1 EACCES
 
# Summary: For any denial, check in order:
# 1. DAC permissions (ls -la)
# 2. MAC (ls -Z, ausearch for SELinux; dmesg for AppArmor)
# 3. Capabilities (getpcaps)
# 4. Namespace visibility (ls -la /proc/PID/ns)
# 5. Seccomp filters (grep Seccomp /proc/PID/status)

Policy-as-Code

Modern infrastructure treats authorization policies as code—version controlled, reviewed, tested, and deployed through CI/CD pipelines. SELinux policies, AppArmor profiles, and cloud IAM policies can all be managed this way. This approach provides audit trails, enables rollback, and allows policy to evolve with the application while maintaining security guarantees.

Summary: Controlling Access

Authorization determines what authenticated subjects may do with system resources. Operating systems implement authorization through discretionary controls, mandatory access control, role-based access, and capabilities—often layered together for defense in depth. Let's consolidate our understanding:

Key Takeaways

•Authorization complements authentication — Identity verification enables meaningful access control decisions.
•DAC gives owners control — Flexible but vulnerable to confused deputy and insider threats.
•MAC provides system-wide enforcement — Security labels and mandatory policies confine even compromised processes.
•RBAC simplifies administration — Roles abstract permissions from users, enabling scalable management.
•Capabilities bundle authority with reference — Possession is authorization, enabling fine-grained delegation.
•Least privilege is essential — Every unnecessary privilege is an exploitation opportunity.

Module Complete:

With this page, we complete Module 1: Protection Goals. We've explored the five fundamental security objectives:

Confidentiality — Protecting information from unauthorized disclosure
Integrity — Ensuring data remains accurate and unmodified
Availability — Keeping systems accessible when needed
Authentication — Verifying identity claims
Authorization — Determining permitted actions

These five goals form the conceptual foundation for all security mechanisms. Every firewall rule, every access control list, every encryption scheme ultimately serves one or more of these goals. Understanding them deeply enables you to reason about security at any level of system design.

Module Complete

Congratulations! You've completed Module 1: Protection Goals. You now understand the fundamental security objectives that operating systems must achieve: Confidentiality, Integrity, Availability, Authentication, and Authorization. In the next module, we'll explore Protection Domains—how operating systems create isolated execution contexts with different privilege levels to implement these protection goals.

5 / 5

Loading learning content...

Operating SystemsProtection Mechanisms

Protection Goals

LevelIntermediate

Duration60 mins

TopicProtection Mechanisms

5 / 5

Authorization

Deciding What You Can Do

What You Will Learn

Authorization Fundamentals

Authorization requires three pieces of information:

Subject (or Principal): The entity requesting access—typically a user or process
Object (or Resource): The thing being accessed—files, devices, memory, services
Operation: The action being requested—read, write, execute, delete, etc.

Authorization vs. Authentication:

These concepts are distinct but related:

Authentication: Verifying 'you are alice'
Authorization: Determining 'alice may read /home/alice/file.txt'

Authentication precedes authorization. First, verify identity; then, consult authorization policy for that identity.

Core Authorization Concepts
Concept	Definition	Example in Unix
Subject	Entity requesting access	User (UID), Process, Group (GID)
Object	Resource being accessed	File, directory, device, socket
Operation	Action being requested	Read, write, execute, chmod
Permission	Right to perform operation	rwx bits, ACL entries
Policy	Rules determining access	File mode bits, SELinux policy
Reference Monitor	Enforces policy on every access	Kernel permission checks, LSM

The Reference Monitor Concept:

The reference monitor is a security component that mediates all access between subjects and objects. It is:

Always invoked: Cannot be bypassed
Tamper-proof: Cannot be modified
Verifiable: Small enough to analyze

Fail-Safe Defaults

Discretionary Access Control (DAC)

Traditional Unix Permissions:

The classic Unix permission model is DAC. Every file has:

An owner (user) who can set permissions
A group that may have different permissions
Permissions for others (everyone else)

For each category, three bits control: read (r), write (w), execute (x). This creates the familiar 'rwxrwxrwx' notation seen in ls -l output.

Unix Permission Bits
Permission	On Files	On Directories	Octal Value
Read (r)	View file contents	List directory contents	4
Write (w)	Modify file contents	Create/delete files in directory	2
Execute (x)	Run as program	Enter directory (cd)	1
SetUID (s)	Run as owner	N/A	4000
SetGID (s)	Run as group	New files inherit group	2000
Sticky (t)	N/A	Only owner can delete their files	1000

Unix Permission Checking
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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
#include <sys/stat.h>
#include <unistd.h>
#include <stdio.h>
 
/**
 * Demonstrates how Unix permission checking works.
 * This reflects the logic inside the kernel.
 */
 
/* Permission bits */
#define S_IRWXU 0700  /* rwx for owner */
#define S_IRWXG 0070  /* rwx for group */
#define S_IRWXO 0007  /* rwx for others */
 
/**
 * Check if process with given credentials can access file.
 * Simplified version of kernel access check.
 * 
 * Real check considers:
 * - Capabilities (CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH)
 * - Supplementary groups
 * - ACLs if present
 */
int check_permission(struct stat *st, uid_t uid, gid_t gid, 
                     int requested_mode) {
    mode_t mode = st->st_mode;
    mode_t granted;
    
    /* Root (UID 0) bypasses most checks */
    if (uid == 0) {
        /* For execute: at least one execute bit must be set */
        if (requested_mode & X_OK) {
            if (!(mode & (S_IXUSR | S_IXGRP | S_IXOTH))) {
                return -1;  /* No execute permission */
            }
        }
        return 0;  /* Root can do everything else */
    }
    
    /* Determine which permission bits apply */
    if (uid == st->st_uid) {
        /* We are the owner - use owner bits */
        granted = (mode >> 6) & 7;
    } else if (gid == st->st_gid) {
        /* We are in the group - use group bits */
        /* Note: Real check also verifies supplementary groups */
        granted = (mode >> 3) & 7;
    } else {
        /* We are 'other' */
        granted = mode & 7;
    }
    
    /* Check if requested permissions are subset of granted */
    if (requested_mode & R_OK) {
        if (!(granted & 4)) return -1;  /* Read not permitted */
    }
    if (requested_mode & W_OK) {
        if (!(granted & 2)) return -1;  /* Write not permitted */
    }
    if (requested_mode & X_OK) {
        if (!(granted & 1)) return -1;  /* Execute not permitted */
    }
    
    return 0;  /* Access permitted */
}
 
/* 
 * Special permissions: SetUID/SetGID
 * When executable with setuid is run, process gets owner's UID
 */
void explain_setuid() {
    /*
     * /usr/bin/passwd has setuid bit:
     * -rwsr-xr-x 1 root root 54256 Jan 10 08:00 /usr/bin/passwd
     *    ^-- 's' means setuid on owner execute
     * 
     * When alice runs passwd:
     * - Real UID: alice (1000)
     * - Effective UID: root (0)  <-- from setuid
     * 
     * This allows passwd to update /etc/shadow (owned by root)
     * even though alice cannot directly write /etc/shadow.
     */
}
 
/* Check file permissions from user space */
int main() {
    /* access() checks using real UID/GID */
    if (access("/etc/shadow", R_OK) == 0) {
        printf("You can read /etc/shadow\n");
    } else {
        printf("Cannot read /etc/shadow: %m\n");
    }
    
    /* euidaccess() or eaccess() uses effective UID/GID */
    /* This matters for setuid programs */
    
    return 0;
}

The Confused Deputy Problem

Mandatory Access Control (MAC)

Why MAC Exists:

Labels and Security Levels:

MAC vs DAC Comparison
Aspect	DAC	MAC
Who sets policy	Resource owner	System administrator
User can change permissions	Yes	No (unless admin grants)
Root can bypass	Yes	Not necessarily
Focus	User convenience	System-wide security
Typical use	General purpose systems	High-security environments
Complexity	Simple	Complex policies
Examples	Unix permissions, Windows ACLs	SELinux, AppArmor, MLS

SELinux:

Type Enforcement:

SELinux primarily uses Type Enforcement (TE). Policy rules have the form:

allow source_domain target_type:class permissions;

For example: allow httpd_t httpd_sys_content_t:file read;

This permits the Apache web server (httpd_t domain) to read files labeled httpd_sys_content_t. Apache cannot read files with other labels, even if Unix permissions would allow it.

SELinux in Action
Bash
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
41
42
43
44
45
46
47
48
# SELinux adds security labels to all subjects and objects
# Labels have format: user:role:type:level
 
# View file security context
$ ls -Z /var/www/html/index.html
-rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0 index.html
                                        ^^^^^^^^^^^^^^^^^^^^^^^^^
                                        SELinux type
 
# View process security context  
$ ps -eZ | grep httpd
system_u:system_r:httpd_t:s0     1234 ?        00:00:05 httpd
                 ^^^^^^^^
                 Process type/domain
 
# Type Enforcement: httpd_t can read httpd_sys_content_t
# but NOT other types
 
# Create file with wrong label
$ echo "test" > /var/www/html/test.html
$ ls -Z /var/www/html/test.html
-rw-r--r--. root root unconfined_u:object_r:admin_home_t:s0 test.html
 
# Apache cannot read this file (wrong type)!
# Access denied even though Unix permissions allow it
 
# Check for SELinux denials in audit log
$ ausearch -m AVC -ts recent
type=AVC msg=audit(...): avc: denied { read } for pid=1234 
  comm="httpd" name="test.html" 
  scontext=system_u:system_r:httpd_t:s0 
  tcontext=unconfined_u:object_r:admin_home_t:s0 
  tclass=file permissive=0
 
# Fix the label
$ restorecon -v /var/www/html/test.html
# Or manually:
$ chcon -t httpd_sys_content_t /var/www/html/test.html
 
# Now Apache can read it
 
# Key SELinux commands:
getenforce          # Show current mode
setenforce 0|1      # Set permissive (0) or enforcing (1)
sesearch            # Query loaded policy
seinfo              # Show policy statistics  
audit2allow         # Generate policy from denials
sepolicy            # Analyze installed policies

Defense Against Compromised Software

Role-Based Access Control (RBAC)

The RBAC Model:

Users: Individual identities (people, service accounts)
Roles: Job functions (admin, operator, auditor, developer)
Permissions: Rights to perform operations on objects
Sessions: Active role activations by users

A user may be assigned multiple roles. During a session, a user can activate a subset of their roles. Permissions for a session are the union of permissions from active roles.

Why RBAC?

RBAC Implementation in Operating Systems
System	RBAC Feature	How It Works
Linux (sudo)	Sudoers roles	Groups in sudoers grant command execution rights
SELinux	SELinux roles	Roles determine available domains for users
Solaris RBAC	Rights profiles	Profiles bundle authorizations and commands
Windows	Built-in groups	Administrators, Users, Power Users, etc.
Windows	Group Policy	Assign rights via security groups
FreeBSD	MAC Framework	Biba, MLS labels with role hierarchies

RBAC with sudoers
Bash
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
41
42
43
44
45
46
47
48
49
50
51
# /etc/sudoers - RBAC-style role definitions
 
# Define command aliases (permission bundles)
Cmnd_Alias DATABASE = /usr/bin/mysql, /usr/bin/mysqldump, \
                      /usr/bin/pg_dump, /usr/bin/psql
 
Cmnd_Alias NETWORKING = /sbin/ifconfig, /sbin/ip, /sbin/iptables, \
                        /sbin/route, /usr/bin/ss
 
Cmnd_Alias SERVICES = /bin/systemctl start *, \
                      /bin/systemctl stop *, \
                      /bin/systemctl restart *, \
                      /bin/systemctl status *
 
Cmnd_Alias READONLY = /usr/bin/cat, /usr/bin/less, /usr/bin/head, \
                      /usr/bin/tail, /bin/ls
 
Cmnd_Alias DANGEROUS = /bin/rm, /bin/dd, /sbin/fdisk, /sbin/mkfs.*
 
# Define roles (groups) and their permissions
 
# Database administrators - full database access
%dba_role ALL=(ALL) DATABASE
 
# Network operators - network configuration
%netops_role ALL=(ALL) NETWORKING
 
# Service operators - start/stop services
%service_ops ALL=(ALL) SERVICES
 
# Security auditors - read-only access to logs
%auditor_role ALL=(ALL) NOPASSWD: READONLY
 
# Junior admins - services and networking, no dangerous commands
%junior_admin ALL=(ALL) SERVICES, NETWORKING, !DANGEROUS
 
# Senior admins - everything except explicit denials
%senior_admin ALL=(ALL) ALL, !DANGEROUS
 
# Full administrators - everything
%wheel ALL=(ALL) ALL
 
# Role assignment happens via group membership:
# usermod -aG dba_role alice     # Alice gets database admin role
# usermod -aG netops_role bob    # Bob gets network operator role
# usermod -aG auditor_role carol # Carol gets auditor role
 
# Verify effective permissions
$ sudo -l -U alice
User alice may run the following commands:
    (ALL) /usr/bin/mysql, /usr/bin/mysqldump, /usr/bin/pg_dump, /usr/bin/psql

Separation of Duties

Capability-Based Security

What Is a Capability?

A capability is an unforgeable token that references an object and specifies permitted operations. Key properties:

Combines designation and authority: The capability is both the name and the permission
Unforgeable: Cannot be created or modified except through authorized means
Transferable: Can be passed to other processes (delegation)
Revocable: Can be invalidated (though this is often challenging)

Real-World Analogy:

Capability Advantages

•No confused deputy problem - authority follows capability
•Fine-grained delegation without central administration
•Simpler analysis of authority - follow the capabilities
•Natural fit for object-oriented/component systems
•No ambient authority - must explicitly pass capabilities

Capability Challenges

•Revocation is difficult - all copies must be invalidated
•Auditing is complex - 'who can access X?' requires tracing all capabilities
•Capability leakage - accidentally passing too many rights
•Naming and capability conflation can be awkward
•Less familiar model - harder to reason about for some

Linux Capabilities:

Linux implements a form of capabilities that subdivides root privilege. Instead of all-or-nothing superuser, root's powers are divided into ~40 distinct capabilities:

CAP_NET_ADMIN: Configure network interfaces
CAP_SYS_ADMIN: Many administrative operations
CAP_DAC_OVERRIDE: Bypass file permission checks
CAP_SETUID: Change UID
CAP_KILL: Send signals to any process

Processes can have capabilities without being root, and root processes can drop capabilities to limit damage from compromise.

Linux Capabilities
Bash
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
41
42
43
44
45
46
47
48
49
50
# Linux capabilities subdivide root privilege
 
# View capabilities of a process
$ getpcaps $$
Capabilities for 1234: =
 
# View capabilities of a binary
$ getcap /usr/bin/ping
/usr/bin/ping = cap_net_raw+ep
 
# ping needs CAP_NET_RAW to send ICMP packets
# Before capabilities: ping was setuid root (dangerous)
# With capabilities: ping only has network rights
 
# Set capabilities on binary (requires CAP_SETFCAP)
$ sudo setcap cap_net_bind_service+ep /usr/local/bin/myserver
# Now myserver can bind to ports <1024 without being root
 
# Capability sets in a process:
# Permitted (P): Max capabilities process can acquire
# Effective (E): Currently active capabilities  
# Inheritable (I): Passed to child processes via exec
# Bounding: Upper limit, can only be reduced
 
# Drop capabilities for defense in depth
# /usr/bin/myapp.wrapper:
#!/bin/bash
# Drop all capabilities except what's needed
exec capsh \
    --caps="cap_net_bind_service+eip" \
    --keep=1 \
    --user=nobody \
    --addamb=cap_net_bind_service \
    -- -c "/usr/bin/myapp"
 
# View a running process's capabilities
$ cat /proc/1234/status | grep Cap
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
 
# Decode capability bits
$ capsh --decode=0000003fffffffff
 
# Run command with only specific capabilities
$ sudo capsh --caps='cap_sys_admin+eip cap_dac_read_search+eip' \
    --keep=1 --uid=1000 --gid=1000 \
    -- -c "ls -la /root"

File Descriptors as Capabilities

The Principle of Least Privilege

Why Least Privilege Matters:

Every unnecessary privilege is an opportunity for:

Accidental damage: Mistakes with powerful tools cause more harm
Malicious exploitation: Attackers who compromise a process inherit its privileges
Privilege escalation: Unneeded privileges may be stepping stones to higher privileges

Implementing Least Privilege:

Least privilege isn't a one-time configuration—it's an ongoing discipline:

Grant minimal initial privileges: Start with nothing, add only what's needed
Drop privileges when no longer needed: After privileged operations complete, relinquish extra rights
Separate privileged and unprivileged code: Put privileged operations in small, auditable components
Limit privilege scope: Grant privileges for specific resources, not all resources

Least Privilege Techniques

•Run as unprivileged user — Never run services as root unless absolutely necessary. Create service accounts with minimal rights.
•Drop capabilities — After privileged initialization, drop unneeded Linux capabilities.
•Privilege separation — Split privileged and unprivileged code into separate processes. OpenSSH uses this extensively.
•chroot/containers — Restrict file system view to only required directories.
•seccomp — Limit available system calls to only those needed.
•MAC policies — SELinux/AppArmor confine processes to required resource access.
•Resource limits — ulimit, cgroups prevent processes from consuming excessive resources.
•Time-limited privileges — Sudo timestamps, session timeouts, temporary access.

Privilege Separation in Code
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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
#include <unistd.h>
#include <sys/types.h>
#include <pwd.h>
#include <grp.h>
#include <sys/prctl.h>
#include <linux/seccomp.h>
 
/*
 * Example: Web server privilege separation
 * 
 * Pattern: Start as root to bind port 80,
 * then immediately drop privileges.
 */
 
int main() {
    int listen_fd;
    struct sockaddr_in addr;
    
    /* ===== PRIVILEGED SECTION ===== */
    /* This code runs as root */
    
    /* Create socket and bind to privileged port 80 */
    listen_fd = socket(AF_INET, SOCK_STREAM, 0);
    addr.sin_family = AF_INET;
    addr.sin_port = htons(80);
    addr.sin_addr.s_addr = INADDR_ANY;
    
    if (bind(listen_fd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
        perror("bind");
        return 1;
    }
    
    listen(listen_fd, 128);
    
    /* ===== DROP PRIVILEGES ===== */
    
    /* Get target user info */
    struct passwd *pw = getpwnam("www-data");
    if (pw == NULL) {
        fprintf(stderr, "User www-data not found\n");
        return 1;
    }
    
    /* Change to restricted directory */
    if (chroot("/var/www") != 0) {
        perror("chroot");
        return 1;
    }
    chdir("/");
    
    /* Drop supplementary groups */
    if (setgroups(0, NULL) != 0) {
        perror("setgroups");
        return 1;
    }
    
    /* Drop group privileges (must be before setuid) */
    if (setgid(pw->pw_gid) != 0) {
        perror("setgid");
        return 1;
    }
    
    /* Drop user privileges */
    if (setuid(pw->pw_uid) != 0) {
        perror("setuid");
        return 1;
    }
    
    /* Prevent regaining privileges */
    if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) != 0) {
        perror("prctl");
        /* Non-fatal, but log it */
    }
    
    /* 
     * Optional: Further restrict with seccomp
     * Allow only needed system calls
     */
    
    /* ===== UNPRIVILEGED SECTION ===== */
    /* Now running as www-data, chrooted to /var/www */
    /* Cannot bind new privileged ports */
    /* Cannot access files outside /var/www */
    /* Cannot regain root privileges */
    
    /* Main server loop now runs with minimum privileges */
    while (1) {
        int client_fd = accept(listen_fd, NULL, NULL);
        handle_request(client_fd);  /* Runs unprivileged */
        close(client_fd);
    }
    
    return 0;
}

The Privilege Creep Problem

Authorization in Practice

Linux Security Module (LSM) Framework:

Authorization Priority:

In Linux with SELinux:

DAC check first: Traditional Unix permissions
Capability check: Linux capabilities may override DAC
LSM/MAC check: SELinux policy (if enabled)

Access is permitted only if all applicable layers permit it. A single deny from any layer denies access.

Layered Authorization Example
Check	What's Verified	Denial Result
DAC (permissions)	Unix mode bits allow operation	EACCES (Permission denied)
DAC (ownership)	User/group matches owner/group	EACCES
Capabilities	Process has required capability	EPERM (Operation not permitted)
SELinux	Policy allows domain->type access	EACCES (with AVC audit message)
AppArmor	Profile allows path access	EACCES (with audit message)
Namespaces	Resource visible in namespace	ENOENT (No such file)
seccomp	Syscall in allowed set	SIGSYS or EPERM

Tracing Authorization Decisions
Bash
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
41
42
43
44
45
46
47
48
49
50
51
52
53
# Debugging authorization denials
 
# Scenario: Process cannot read a file - why?
 
# Check DAC permissions
$ ls -la /path/to/file.txt
-rw------- 1 alice alice 1234 Jan 15 10:00 file.txt
 
# If running as bob, DAC will deny (no 'other' permissions)
 
# Check if SELinux is involved
$ getenforce
Enforcing
 
# Check SELinux context requirements
$ ls -Z /path/to/file.txt
-rw-------. alice alice unconfined_u:object_r:user_home_t:s0 file.txt
 
$ ps -eZ | grep myprocess
system_u:system_r:httpd_t:s0     myprocess
 
# SELinux may deny httpd_t -> user_home_t access
 
# Check for SELinux denials
$ ausearch -m AVC -ts recent
 
# Check AppArmor (if used instead of SELinux)
$ aa-status
$ dmesg | grep apparmor
 
# Check if capabilities are relevant
$ getpcaps $(pgrep myprocess)
# Does process need CAP_DAC_READ_SEARCH or CAP_DAC_OVERRIDE?
 
# Check namespace isolation
$ ls -la /proc/$(pgrep myprocess)/ns/
# Is the process in a different mount namespace?
 
# Check seccomp filtering
$ grep Seccomp /proc/$(pgrep myprocess)/status
Seccomp:    2
# 2 means SECCOMP_MODE_FILTER (BPF filtering active)
 
# Strace to see actual syscall and errno
$ strace -f -e trace=file myprocess 2>&1 | grep -E "open|access"
openat(AT_FDCWD, "/path/to/file.txt", O_RDONLY) = -1 EACCES
 
# Summary: For any denial, check in order:
# 1. DAC permissions (ls -la)
# 2. MAC (ls -Z, ausearch for SELinux; dmesg for AppArmor)
# 3. Capabilities (getpcaps)
# 4. Namespace visibility (ls -la /proc/PID/ns)
# 5. Seccomp filters (grep Seccomp /proc/PID/status)

Policy-as-Code

Summary: Controlling Access

Key Takeaways

•Authorization complements authentication — Identity verification enables meaningful access control decisions.
•DAC gives owners control — Flexible but vulnerable to confused deputy and insider threats.
•MAC provides system-wide enforcement — Security labels and mandatory policies confine even compromised processes.
•RBAC simplifies administration — Roles abstract permissions from users, enabling scalable management.
•Capabilities bundle authority with reference — Possession is authorization, enabling fine-grained delegation.
•Least privilege is essential — Every unnecessary privilege is an exploitation opportunity.

Module Complete:

With this page, we complete Module 1: Protection Goals. We've explored the five fundamental security objectives:

Confidentiality — Protecting information from unauthorized disclosure
Integrity — Ensuring data remains accurate and unmodified
Availability — Keeping systems accessible when needed
Authentication — Verifying identity claims
Authorization — Determining permitted actions

Module Complete

5 / 5