CS 155 Spring 2017

Secure Architecture
Principles
• Isolation and Least Privilege
• Access Control Concepts
• Operating Systems
• Browser Isolation and Least Privilege

John Mitchell
Secure Architecture
Principles

Isolation and
Least Privilege
John Mitchell
 Principles of Secure Design
• Compartmentalization
– Isolation
– Principle of least privilege
• Defense in depth
– Use more than one security mechanism
– Secure the weakest link
– Fail securely
• Keep it simple

John Mitchell
 Principle of Least Privilege
• Principle of Least Privilege
– A system module should only have the minimal
privileges needed for its intended purposes
• What’s a privilege?
– Ability to access or modify a resource
• Assumes compartmentalization and isolation
– Separate the system into isolated compartments
– Limit interaction between compartments

John Mitchell
 Monolithic design

Network Network

User input
System User device

File system File system

John Mitchell
 Monolithic design

Network Network

User input
System User device

File system File system

John Mitchell
 Monolithic design

Network Network

User input
System User display

File system File system

John Mitchell
 Component design

Network Network

User input User display

File system File system

John Mitchell
 Component design

Network Network

User input User device

File system File system

John Mitchell
 Component design

Network Network

User input User device

File system File system

John Mitchell
 Principle of Least Privilege
• Principle of Least Privilege
– A system module should only have the minimal
privileges needed for its intended purposes
• What’s a privilege?
– Ability to access or modify a resource
• Assumes compartmentalization and isolation
– Separate the system into isolated compartments
– Limit interaction between compartments

John Mitchell
 Example: Mail Agent
• Requirements
– Receive and send email over external network
– Place incoming email into local user inbox files
• Sendmail
– Traditional Unix
– Monolithic design
– Historical source of many vulnerabilities
• Qmail
– Compartmentalized design
John Mitchell
 OS Basics (before examples)
• Isolation between processes
– Each process has a UID
• Two processes with same UID have same permissions
– A process may access files, network sockets, ….
• Permission granted according to UID
• Relation to previous terminology
– Compartment defined by UID
– Privileges defined by actions allowed on system resources

John Mitchell
 Qmail design
• Isolation based on OS isolation
– Separate modules run as separate “users”
– Each user only has access to specific resources
• Least privilege
– Minimal privileges for each UID
– Only one “setuid” program
• setuid allows a program to run as different users
– Only one “root” program
• root program has all privileges
John Mitchell
 Structure of qmail
qmail-smtpd qmail-inject

qmail-queue
Incoming external mail Incoming internal mail

qmail-send

qmail-rspawn qmail-lspawn

qmail-remote qmail-local
John Mitchell
 Isolation by Unix UIDs
qmailq – user who is allowed to read/write mail queue
qmaild
user
qmail-smtpd qmailq qmail-inject

qmail-queue

qmail-send
qmailr qmails root
qmail-rspawn qmail-lspawn

setuid user
qmailr user
qmail-remote qmail-local
John Mitchell
 Structure of qmail
qmail-smtpd qmail-inject

qmail-queue
Reads incoming mail directories
Splits message into header, body
Signals qmail-send
qmail-send

qmail-rspawn qmail-lspawn

qmail-remote qmail-local
John Mitchell
 Structure of qmail
qmail-smtpd qmail-inject

qmail-queue
qmail-send signals
• qmail-lspawn if local
• qmail-remote if remote qmail-send

qmail-rspawn qmail-lspawn

qmail-remote qmail-local
John Mitchell
 Structure of qmail
qmail-smtpd qmail-inject

qmail-queue

qmail-send

qmail-lspawn
qmail-lspawn
• Spawns qmail-local
• qmail-local runs with ID of user
receiving local mail qmail-local
John Mitchell
 Structure of qmail
qmail-smtpd qmail-inject

qmail-queue

qmail-send

qmail-lspawn
qmail-local
• Handles alias expansion
• Delivers local mail
• Calls qmail-queue if needed qmail-local
John Mitchell
 Structure of qmail
qmail-smtpd qmail-inject

qmail-queue

qmail-send

qmail-rspawn

qmail-remote
qmail-remote • Delivers message to remote MTA
John Mitchell
 Isolation by Unix UIDs
qmailq – user who is allowed to read/write mail queue
qmaild
user
qmail-smtpd qmailq qmail-inject

qmail-queue
setuid

qmail-send
qmailr qmails root root
qmail-rspawn qmail-lspawn

setuid user
qmailr user
qmail-remote qmail-local
John Mitchell
 Least privilege
qmail-smtpd qmail-inject

setuid qmail-queue

qmail-send

qmail-rspawn qmail-lspawn
root

qmail-remote qmail-local
John Mitchell
 Android process isolation
• Android application sandbox
– Isolation: Each application runs with its own UID in own VM
• Provides memory protection
• Communication limited to using Unix domain sockets
• Only ping, zygote (spawn another process) run as root
– Interaction: reference monitor checks permissions on inter-
component communication
– Least Privilege: Applications announces permission
• User grants access at install time
John Mitchell
John Mitchell
Isolation: different apps under different UIDs
App

John Mitchell
Isolation: different apps under different UIDs
UID1 App UID2 App

John Mitchell
 Privileges set at install time
UID1, priv 1, priv 2, … App UID2, priv 3, priv 4, … App

John Mitchell
 Discussion?
• Principle of Least Privilege
• Qmail example
• Android app sandbox example

John Mitchell
Secure Architecture
Principles

Access Control
Concepts
John Mitchell
 Access control
• Assumptions
– System knows who the user is
• Authentication via name and password, other credential
– Access requests pass through gatekeeper (reference monitor)
• System must not allow monitor to be bypassed

Reference
monitor
User
process access request ? Resource

policy
John Mitchell
 Access control matrix [Lampson]
Objects

File 1 File 2 File 3 … File n

User 1 read write - - read

User 2 write write write - -

Subjects
User 3 - - - read read

User m read write read write read

John Mitchell
 Implementation concepts
File 1 File 2 …
• Access control list (ACL) User 1 read write -
– Store column of matrix
User 2 write write -
with the resource
User 3 - - read
• Capability
– User holds a “ticket” for …
each resource User m Read write write
– Two variations
• store row of matrix with user, under OS control
• unforgeable ticket in user space

Access control lists are widely used, often with groups

Some aspects of capability concept are used in many systems John Mitchell
ACL: my name is on the list

John Mitchell
Capability: I have a ticket

John Mitchell
 ACL vs Capabilities
• Access control list
– Associate list with each object
– Check user/group against list
– Relies on authentication: need to know user
• Capabilities
– Capability is unforgeable ticket
• Random bit sequence (or managed by OS)
• Can be passed from one process to another
– Reference monitor checks ticket
• Does not need to know identify of user/process John Mitchell
 ACL vs Capabilities
• Delegation
– Cap: Process can pass capability at run time
– ACL: Try to get owner to add permission to list?
• More common: let other process act under current user
• Revocation
– ACL: Remove user or group from list
– Cap: Try to get capability back from process?
• Possible in some systems if appropriate bookkeeping
– OS knows which data is capability
– If capability is used for multiple resources, have to revoke all or none …
• Indirection: capability points to pointer to resource
– If C  P  R, then revoke capability C by setting P=0
John Mitchell
 Process creation: ACL vs Capabilities

User U Capabilty c,d,e

Process P Process P

User U Capabilty c,e

Process Q Process Q

User U Capabilty c
Process R Process R

John Mitchell
 Roles (aka Groups)
• Role = set of users
– Administrator, PowerUser, User, Guest
– Assign permissions to roles; each user gets permission
• Role hierarchy
– Partial order of roles Administrator

– Each role gets PowerUser

permissions of roles below
User
– List only new permissions
given to each role Guest

John Mitchell
 Role-Based Access Control
Individuals Roles Resources

engineering Server 1

marketing Server 2

Server 3
human res

Advantage: users change more frequently than roles

John Mitchell
 Access control summary
• Access control involves reference monitor
– Check permissions: user info, action yes/no
– Important: must be no way to bypass this check
• Access control matrix
– Two implementations: access control lists vs capabilities
– Advantages and disadvantages of each
• Role-based access control
– Use group as “user info”; use group hierarchies

John Mitchell
 Discussion?
• Access control matrix
– What are the advantages of access control lists (ACL)
– What are the advantages of capabilities
• Role-based access control
– Why is this helpful?

John Mitchell
Secure Architecture
Principles
Operating Systems

John Mitchell
 Unix
• What access control concepts are used?
– Truncated access control list
– A form of role-based access control
File 1 File 2 … File 1 File 2 …

User 1 read write - Owner read write -

User 2 write write - Group write write -

User 3 - - read Other - - read

Role r Read write write

John Mitchell
 Unix access control
• Process has user id File 1 File 2 …

– Inherit from creating process Owner read write -

– Process can change id Group write write -

• Restricted set of options Other - - read

– Special “root” id
• All access allowed
• File has access control list (ACL)
– Grants permission to users
– Three “roles”: owner, group, other

John Mitchell
 Unix file access control list
• Each file has owner and group
• Permissions set by owner
– Read, write, execute
rwx rwx rwx
– Owner, group, other
ownr grp othr
– Represented by vector of
four octal values
• Only owner, root can change permissions
– This privilege cannot be delegated or shared
• Setid bits – Discuss in a few slides

John Mitchell
 Example directory listing
access owner group size modification name

John Mitchell
 Process effective user id (EUID)
• Each process has three Ids (+ more under Linux)
– Real user ID (RUID)
• same as the user ID of parent (unless changed)
• used to determine which user started the process
– Effective user ID (EUID)
• from set user ID bit on the file being executed, or sys call
• determines the permissions for process
– file access and port binding
– Saved user ID (SUID)
• So previous EUID can be restored

• Real group ID, effective group ID, used similarly

John Mitchell
 Process Operations and IDs
• Root
– ID=0 for superuser root; can access any file
• Fork and Exec
– Inherit three IDs, except exec of file with setuid bit
• Setuid system call
– seteuid(newid) can set EUID to
• Real ID or saved ID, regardless of current EUID
• Any ID, if EUID is root

• Details are actually more complicated

– Several different calls: setuid, seteuid, setreuid John Mitchell
 Setid bits on executable Unix file
• Three setid bits
– Setuid – set EUID of process to ID of file owner
– Setgid – set EGID of process to GID of file
– Sticky
• Off: if user has write permission on directory, can
rename or remove files, even if not owner
• On: only file owner, directory owner, and root can
rename or remove file in the directory

John Mitchell
 Example
Owner 18
RUID 25 SetUID
…; program
…;
exec( );
Owner 18
-rw-r--r-- …;
read/write …; RUID 25
file EUID 18
i=getruid()
Owner 25 setuid(i);
-rw-r--r-- RUID 25
read/write …; EUID 25
file …;
John Mitchell
 Unix access control summary
• Good things
– Some protection from most users
– Flexible enough to make practical systems possible
• Main limitation
– Coarse-grained ACLs – user, group, other
– Too tempting to use root privileges
– No way to assume some root privileges without all

John Mitchell
 Weakness in unix isolation, privileges
• Network-facing Daemons
– Root processes with network ports open to all remote parties, e.g.,
sshd, ftpd, sendmail, …
• Rootkits
– System extension via dynamically loaded kernel modules
• Environment Variables
– System variables such as LIBPATH that are shared state across
applications. An attacker can change LIBPATH to load an attacker-
provided file as a dynamic library

John Mitchell
 Weakness in unix isolation, privileges
• Shared Resources
– Since any process can create files in /tmp directory, an untrusted
process may create files that are used by arbitrary system processes
• Time-of-Check-to-Time-of-Use (TOCTTOU)
– Typically, a root process uses system call to determine if initiating user
has permission to a particular file, e.g. /tmp/X.
– After access is authorized and before the file open, user may change
the file /tmp/X to a symbolic link to a target file /etc/shadow.

John Mitchell
 Access control in Windows
• Full access control lists
– Specify access for groups and users
• Read, modify, change owner, delete
• Some additional concepts
– Tokens
– Security attributes
• Generally, more precise, more flexible than Unix
– Can define new permissions
– Can transfer some but not all privileges (cf. capabilities)
John Mitchell
John Mitchell
 Process has set of tokens
• Called the process “security context”
– Privileges, accounts, and groups associated with the
process or thread
– Presented as set of tokens
• Interesting feature: impersonation token
– Used temporarily to adopt a different security context,
usually of another user (similar to use of capability/setuid)

John Mitchell
 Object has security descriptor
• Specifies who can perform what actions on the object
– Header (revision number, control flags, …)
– SID of the object's owner
– SID of the primary group of the object
– Two attached optional lists:
• Discretionary Access Control List (DACL) – users, groups, …
• System Access Control List (SACL) – system logs, ..

John Mitchell
 Example access request
User: Mark
Access token Group1: Administrators Access request: write
Group2: Poets Action: denied

Revision Number • User Mark requests write permission

Control flags • Descriptor denies permission to group
Owner SID
Group SID • Reference Monitor denies request
DACL Pointer (DACL for access, SACL for audit and logging)
Security SACL Pointer
descriptor Deny Priority:
Poets Explicit Deny
Read, Write Explicit Allow
Allow
Mark Inherited Deny
Read, Write Inherited Allow
John Mitchell
 Impersonation Tokens (compare to setuid)
• Process adopts security attributes of another
– Client passes impersonation token to server
• Client specifies impersonation level
– Anonymous
• Token has no information about the client
– Identification
• Obtain the SIDs of client and client's privileges, but server cannot
impersonate the client
– Impersonation
• Impersonate the client
– Delegation
• Lets server impersonate client on local, remote systems John Mitchell
 Windows access control summary
• Full access control lists
– Specify access for groups and users
• Read, modify, change owner, delete
• Some additional concepts
– Tokens
– Security attributes
• Generally, more precise, more flexible than Unix
– Can define new permissions
– Can transfer some but not all privileges (cf. capabilities)
John Mitchell
 Weakness in isolation, privileges
• Similar problems to Unix
– E.g., Rootkits leveraging dynamically loaded kernel modules
• Windows Registry
– Global hierarchical database to store data for all programs
– Registry entry can be associated with a security context that
limits access; common to be able to write sensitive entry
• Can have permissions enabled by default
– Historically, many Windows deployments also came with full
permissions and functionality enabled

John Mitchell
 Discussion?
• Unix access control
– What information is associated with a process?
– What information is associated with a resource (file)?
– How are they compared?
– What form of delegation of authority is possible?
• Windows access control
– What information is associated with a process?
– What information is associated with a resource (file)?
– How are they compared?
– What form of delegation of authority is possible?
• Comparison, pros and cons?
John Mitchell
Secure Architecture
Principles
Browser Isolation
and Least Privilege
John Mitchell
 Let’s look at browser example
• Browser is an execution environment
– Has access control policies similar to an OS
• Browser runs under control of an OS
– Use least privilege to keep the browser code secure against
attacks that would break the browser enforcement of web
security policy

Topic here: implementation of browser using least privilege

John Mitchell
 Web browser: an analogy

Operating system Web browser

• Subject: Processes • Subject: web content (JavaScript)
– Has User ID (UID, SID) – Has “Origin”
– Discretionary access control – Mandatory access control
• Objects • Objects
– File – Document object model
– Network – Frames
– … – Cookies / localStorage
• Vulnerabilities • Vulnerabilities
– Untrusted programs – Cross-site scripting
– Buffer overflow – Implementation bugs
– … – …
The web browser enforces its own internal policy. If the browser
implementation is corrupted, this mechanism becomes unreliable.
John Mitchell
 Components of security policy
• Frame-Frame relationships
– canScript(A,B)
• Can Frame A execute a script that manipulates
arbitrary/nontrivial DOM elements of Frame B?
– canNavigate(A,B)
• Can Frame A change the origin of content for Frame B?
• Frame-principal relationships
– readCookie(A,S), writeCookie(A,S)
• Can Frame A read/write cookies from site S?
John Mitchell
 Chromium Security Architecture
• Browser ("kernel")
– Full privileges (file system,
networking)
• Rendering engine
– Can have multiple processes
– Sandboxed
• One process per plugin
– Full privileges of browser

John Mitchell
Task Allocation

John Mitchell
Chromium
Communicating sandboxed
components

See: http://dev.chromium.org/developers/design-documents/sandbox/ John Mitchell

 Leverage OS Isolation
• Sandbox based on four OS mechanisms (e.g., Windows)
– A restricted token
– The Windows job object
– The Windows desktop object
– Windows integrity levels
• Specifically, the rendering engine
– adjusts security token by converting SIDS to DENY_ONLY, adding restricted
SID, and calling AdjustTokenPrivileges
– runs in a Windows Job Object, restricting ability to create new processes,
read or write clipboard, ..
– runs on a separate desktop, mitigating lax security checking of some
Windows APIs
See: http://dev.chromium.org/developers/design-documents/sandbox/ John Mitchell
 Evaluation: CVE count
• Total CVEs:

• Arbitrary code execution vulnerabilities:

John Mitchell
 Discussion?
• How does Chrome architecture use principle of least privilege?
– What are the isolated modules?
– Which privileges are given to each module?
• Why is this effective?
• Are there other ways you could use operating system features
to improve isolation and least privilege?

John Mitchell
 Summary
• Security principles
– Isolation
– Principle of Least Privilege
– Qmail, Android examples
• Access Control Concepts
– Matrix, ACL, Capabilities
• OS Mechanisms
– Unix: UID, ACL, Setuid
– Windows: SID, Tokens, Security Descriptor, Impersonation
• Browser security architecture
– Isolation and least privilege example
John Mitchell