1

CS 161, Summer 2026 @ UC Berkeley

Slides credit: Nick Weaver, Nicholas Ngai, Peyrin Kao, Henry Corrigan-Gibbs, Jonah Bedouch, MIT 6.1600 Staff

Access Control

Lecture 22 (Isolation 3)

Setting Security Policies

Lecture 22, CS 161, Summer 2026

Policies

• Setting Security Policies
• Types of Security Policies
• Delegation
• Capabilities

Examples

• Short Examples
• Long Example: Firewalls

Controlled Sharing

Isolation is great, but the components need to interact somehow.

Today: Building controlled sharing schemes.� Allow boxes to interact, according to some security policy we design.

​

When a box requests to interact with another box, the host takes three steps:

Authenticate

​

Learn who�is sending the request.

Authorize

​

Decide whether the request is allowed.�

Audit

​

Keep a log of all requests and decisions.

Remember to ensure complete mediation: Authenticate, authorize, audit every request!

Won't discuss auditing in detail.�Reminder: The auditing code should be in an isolated box, so attackers can't tamper with logs.

Generalizing with Principals and Objects

Informally: A box requests to interact with another box.

More formally: A principal requests to access an object.

• A principal is an entity that can be authenticated.�Examples: An entire component, a specific user within a component, etc.
• An object is an entity that needs to be protected.�Examples: An entire component, a specific file/database/page within a component, etc.

Authenticate

​

Learn which principal is sending the request.

Authorize

​

Decide whether the request is allowed to access the object.

Audit

​

Keep a log of all requests and decisions.

Conceptual Security Policy: Access Control Matrix

A security policy can be modeled as a 2D matrix:

• Each row represents an object.
• Each column represents a principal.
• Each cell indicates the permissions a principal has for an object.

Conceptually simple, but not practical to use: the matrix gets too big.

The Objects

Practical Security Policy: Access Control List

Practical systems try to represent the matrix data in a more compact format.

• Often uses the fact that the matrix is sparse, i.e. most entries are "No Access."

​

Access control list (ACL): One list per object, with the permissions for that object.

• Can quickly determine who has access to a given object.
• Can store the ACL alongside the object.�Example: If the object is a file, the ACL could be stored in the metadata.

​

Maintaining Security Policies (1/2)

Common problem: Lack of motivation to remove stale permissions.

• EvanBot joins a new team at work.�EvanBot is added to the access control lists for the team's files.
• A month later, EvanBot leaves the team.�Nobody remembers to remove EvanBot from the access control lists.

Result: Security policies often drift to become too lenient.

Maintaining Security Policies (2/2)

ACLs can get very complicated. Real-world example:

Types of Security Policies

Lecture 22, CS 161, Summer 2026

Policies

• Setting Security Policies
• Types of Security Policies
• Delegation
• Capabilities

Examples

• Short Examples
• Long Example: Firewalls

Types of Security Policies

Discretionary Access Control (DAC)

Owner of the object sets its policy.�Owner could be creator of the object.�Other approaches exist.

• Fine-grained: Each owner understands their own needs.
• Flexible: Each object could have a different policy.
• Error-prone: Non-expert users may not know how to set good policies.
• If a user is compromised, all objects they own are compromised, but other users' objects are safe.

Mandatory Access Control (MAC)

A security administrator sets the policy for all objects. (No relation to cryptographic MACs.)�

• Coarse-grained: Admin doesn't know details of each object.
• Inflexible: Everyone must follow the same policy.
• More foolproof: The admin is more security-aware.
• If a user is hacked, their objects are still safe. But if the admin is compromised, everybody's objects are compromised.

Types of Security Policies

Which type of policy is better? In practice, a mix is common.

• Admin enforces a broad mandatory policy.�Example: "Only employees can access classified data."
• Users can add more discretionary policy details to their own files.�Example: "Only CodaBot and EvanBot can access my files."
• Typically, a request is only authorized if it satisfies both policies.

​

More complex policies exist as well. Example: Role-Based Access Control (RBAC).

• Users are assigned to roles.�Example: Faculty, TA, Student, CDSS College Member, L&S College Member, etc.
• Each role is granted permissions.�Example: "All CDSS College Members have building access."
• There could be two admins, one for each task.

Delegation

Lecture 22, CS 161, Summer 2026

Policies

• Setting Security Policies
• Types of Security Policies
• Delegation
• Capabilities

Examples

• Short Examples
• Long Example: Firewalls

Delegation Complicates Access Control

A challenge is delegation: Requests travel multiple hops from principal to object.

• The request could be changed by untrusted intermediates.
• The request could be re-formatted across hops, e.g. HTTP request → SQL query.

By the time the request reaches the object, hard to say where the request came from.

User's web browser

User's laptop

gmail.com web server

Gmail back-end server

Database of emails

I want to delete this email.

The same request could be formatted as HTTP here...

...and later re-formatted as a SQL query here.

Who actually "sent" this request?

Authenticating/Authorizing Delegated Requests

If a request travels from A → B → C, should C authenticate/authorize A or B?

Treat the request as coming from A:

• Less trust: No need to trust intermediates like B.
• Complex: Must secure requests across many hops (e.g. signatures).�
• More granularity: Requests come from specific users.
• Complex: Must have per-user specific policy.

Treat the request as coming from B:

• More trust: Relies on B to properly authenticate/authorize A on behalf of C.
• Simple: No need to worry about securing requests across many hops.�
• Less granularity: All requests are from the "Company Server."
• Simple: Can have a single policy for the entire "Company Server."

A

(Example: Employee Laptop)

B

(Example: Company Server)

C

(Example: Company Database)

Compound Principals

If a request travels from A → B → C, should C authenticate/authorize A or B?

Which approach is better? It depends.

• "The request is from B" loses information about A.�Example: Which specific user sent the request?
• "The request is from A" loses information about B.�Example: Did the request go through the internal company server, or a SQL-injected public web server?

A more sophisticated idea is compound principals: "The request is from A, via B."

• Authentication: Can check that A explicitly delegated permission to B.�Example: A signs a message like "I am using B to manage my emails."
• Authorization: Can check that both A and B are allowed to perform the operation.
• Trade-off: Gives a more complete picture of the request, but adds complexity.

A

(Example: Employee Laptop)

B

(Example: Company Server)

C

(Example: Company Database)

Scoping Delegated Permissions (1/2)

When delegating to other components, limiting the scope of delegation is important.

• Principle of least privilege: Delegate the minimum permissions necessary.

A

B

B can access my files.

Too broad.

A

B

B can access /users/evanbot/doodle.png for the next 3 hours.

Scoped to a specific object.

Scoped to a specific time.

Note: Picking the right time scope can be tricky, because it's not always clear how long a request will take.

Scoping Delegated Permissions (2/2)

An intermediate component must also limit scope when forwarding requests.

• Many users could delegate permissions to the intermediate server.
• If the server attaches all permissions with every request,�an attacker could perform an action using a different user's permissions.

EvanBot

CodaBot

Mallory

Server

Sign(SKEvan, "Server can access my mail.")

Sign(SKCoda, "Server can access my mail.")

Delete Evan's emails.

Database

Sign(SKEvan, "Server can access my mail.")

Sign(SKCoda, "Server can access my mail.")

Delete Evan's emails.

Server must be careful to not attach unneeded permissions.

Capabilities

Lecture 22, CS 161, Summer 2026

Policies

• Setting Security Policies
• Types of Security Policies
• Delegation
• Capabilities

Examples

• Short Examples
• Long Example: Firewalls

Capabilities

Capabilities: If you know the name of the object, you can access the object.

• Names are long, random, and hard-to-guess.
• Example: Unlisted YouTube links. You can only see the video if you know the link.
• Example: API keys. Only users with a valid key can call ban_user("IrHr0Ck", "evan").

​

Capabilities are an alternate approach to authentication and authorization.

• Simple: To delegate, just send the capability string.
• Precise scoping: Each capability string represents one specific object, e.g. one file.
• Hard to track: Unlike ACLs, it's not clear who has access to the object.
• Revocation: Once someone has the capability, they have access forever.�(Possible fix: Scope capability strings to expire after some time.)

​

Hybrid approach: ACLs for long-term objects, capabilities for short-term objects.

​

Short Examples of Access Control

Lecture 22, CS 161, Summer 2026

Policies

• Setting Security Policies
• Types of Security Policies
• Delegation
• Capabilities

Examples

• Short Examples
• Long Example: Firewalls

Access Control Example: Logging

Goal: Design an access control policy for interacting with a logging component.

• Allow appending and reading.
• Do not allow editing or deleting.

Logger

delete_log_entry

edit_log_entry

read_log_entry

append_log_entry

Access Control Examples: OAuth2 Scopes (1/2)

Scenario: I write an app that wants to interact with Discord (an online messaging app).

• We need a way to control what my app can and can't do with data from Discord.

The protocol for this is called OAuth2.

• Before my code can interact with Discord, I need to tell Discord what I want access to.
• Discord generates a link that I can share to my users.

Access Control Examples: OAuth2 Scopes (2/2)

When a user clicks on the link that was generated by Discord, they see a request.

​

The user can approve or deny the request.

​

If the user approves, my app gets an OAuth Token, which acts as a capability, allowing it to access the requested resources from Discord.

• A token can't be used to access a resource the user didn't approve.

The resources my app wants.

Long Example of Access Control: Firewalls

Lecture 22, CS 161, Summer 2026

Policies

• Setting Security Policies
• Types of Security Policies
• Delegation
• Capabilities

Examples

• Short Examples
• Long Example: Firewalls

Access Control Example: Firewalls

A firewall monitors incoming and outgoing network traffic,�according to some access control policy.

• Outbound policy: What traffic is allowed to exit the network?
• Inbound policy: What traffic is allowed to enter the network?

Firewalls enforce isolation by separating a trusted network (e.g. internal company network) from an untrusted network (e.g. the rest of the Internet).

Ensure Complete Mediation: All traffic must be checked by the firewall.

Internet

(Untrusted)

Firewall

Internal Company Network

Access Control Example: Firewalls

Example access control policy:

• Allow all outbound traffic. Internal users can connect to any service.
• Allow inbound traffic in response to an outbound connection.
• Allow inbound traffic to certain trusted services (e.g. SSH)
• Deny all other inbound traffic.

Internet

(Untrusted)

Firewall

Internal Company Network

Allow outbound traffic

Allow trusted inbound traffic

Deny other inbound traffic

Default-deny is better for security. (Default-allow is better for usability, but less secure.)

Enforcing Access Control: Stateless Packet Filters

A packet filter inspects a packet and decides to forward it or drop it.

​

Stateless packet filters have no persistent state.

• All decisions made using the packet itself.
• Works for simple policies, but not for more complex ones.
• Example: "Allow inbound traffic in response to an outbound connection."�Stateless hack: Only allow TCP packets with the ACK flag set.

Enforcing Access Control: Stateful Packet Filters

Stateful packet filters maintain state.

• Example: Track all active connections, reassembling data in packets.
• Operator writes rules for what connections are allowed/denied.
• Ultimately, packets are still forwarded or dropped.

​

Example stateful policies:

• allow tcp connection 4.5.5.4:* -> 3.1.1.2:80�Allow connections from 4.5.5.4, any port, to 3.1.1.2, port 80 (HTTP).
• allow tcp connection *:*/int -> *:*/ext�Allow connections from any internal host, to any external service.
• allow tcp connection *:*/int -> *:80/ext�Allow connections from any internal host, to any external HTTP service.
• allow tcp connection *:*/ext -> 1.2.2.3:80�Allow connections from any external host, to 1.2.2.3, port 80 (HTTP).

Evading Packet Filters (1/3)

Running example policy: Deny all connections containing the string root.

​

Attack: Split the word root across TCP packets.

• No single packet contains root, so the firewall won't stop any of these packets.

Attack: Send the split TCP packets out of order.

• Now the firewall has to reconstruct TCP connections to detect the root message.

✓

✗

✓

o

r

o

t

Firewall

o

r

o

t

Seq = 6

Seq = 4

Seq = 5

Seq = 7

Evading Packet Filters (2/3)

IP packets have a time-to-live (TTL).

• The number of hops a packet may take before the packet is dropped.

The attacker can easily find how many hops away a given server is.

• Send ping packets with increasing TTLs until the server responds.

Attack: Send multiple packets with the same sequence number.

• Set the TTLs on the dummy packets so that they are dropped before they reach the destination.

​

Seq = 4, TTL = 16

n

Seq = 4, TTL = 22

r

r

Seq = 5, TTL = 22

o

o

Seq = 5, TTL = 16

i

Seq = 6, TTL = 22

o

o

Seq = 6, TTL = 16

c

Seq = 7, TTL = 16

e

Seq = 7, TTL = 22

t

o

Firewall

Evading Packet Filters (3/3)

This attack is hard to stop, even for the stateful packet filter.

• TTLs for different packets naturally vary, since packets may take different routes.
• Storing all possible combinations takes exponential space.
• Hard to predict which packets will reach the destination and which won't.

Seq = 4, TTL = 16

n

Seq = 4, TTL = 22

r

r

Seq = 5, TTL = 22

o

o

Seq = 5, TTL = 16

i

Seq = 6, TTL = 22

o

o

Seq = 6, TTL = 16

c

Seq = 7, TTL = 16

e

Seq = 7, TTL = 22

t

o

Firewall

Other Types of Firewalls: Proxy Firewalls

Proxy firewall: Instead of forwarding packets, form two separate connections:�One with the source, and one with the destination.

• The connection could be TCP (layer 4), HTTP(S) (layer 7), etc.
• The firewall acts as a MITM, spoofing the addresses of the end hosts.
• Avoids problems with evasion, since the firewall has direct access to the TCP byte streams.

Firewall

Client (outside)

Server (inside)

TCP

TCP

Spoofed header field.

Spoofed header field.

Alternatives to Allowing Firewall Traffic: VPNs

A virtual private network (VPN) allows someone outside of a network to access the network, as though they were inside.

• The VPN is a server running within the network that acts as a proxy.
• Users authenticate to the VPN and create an encrypted "tunnel."
• The VPN forwards data between user/server through the "tunnel."
• The firewall must include a policy to allow traffic from VPN "tunnels."

Service

Internal Company Network

Firewall

Internet (Insecure)

Encrypted Tunnel

VPN

User

Firewall Pros and Cons

Benefits:

• Centralized management of security policies (single point of control).
• Transparent operation to end users.
• Mitigates security vulnerabilities on end hosts (e.g. block anything that looks like shellcode).

Drawbacks:

• Reduced network connectivity: Some applications don't work well inside a firewall.
• Vulnerability to insiders:
• Employees could be bribed or threatened.
• Devices are often brought from the outside (e.g. cell phones, laptops).
• Once one device is compromised, attackers can spread through the network.
• Could be mitigated by layering firewalls for more sensitive devices.

​

​