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

Monolithic design
Network User input File system Network

System

User device File system

John Mitchell

Monolithic design
Network User input File system Network

System

User device File system

John Mitchell

Monolithic design
Network User input File system Network

System

User display File system

John Mitchell

Component design
Network User input Network User display

File system

File system

John Mitchell

Component design
Network User input Network User device

File system

File system

John Mitchell

Component design
Network User input Network User device

File system

File system

John Mitchell

Principle of Least Privilege

Whats a privilege? Ability to access or modify a resource Assume compartmentalization and isolation Separate the system into independent modules Limit interaction between modules Principle of Least Privilege A system module should only have the minimal privileges needed for its intended purposes
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 Comparmentalized design
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 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-queue qmail-inject

Incoming external mail

qmail-send qmail-rspawn

Incoming internal mail

qmail-lspawn

qmail-remote

qmail-local
John Mitchell

Isolation by Unix UIDs

qmaild
qmail-smtpd qmailq qmail-queue

qmailq user who is allowed to read/write mail queue

qmail-inject

user

qmail-send qmailr qmail-rspawn

qmails

qmail-lspawn setuid user qmail-local

root

qmailr qmail-remote

user
John Mitchell

Structure of qmail
qmail-smtpd
Reads incoming mail directories Splits message into header, body Signals qmail-send

qmail-inject qmail-queue

qmail-send qmail-rspawn qmail-lspawn

qmail-remote

qmail-local
John Mitchell

Structure of qmail
qmail-smtpd qmail-queue qmail-send signals qmail-lspawn if local qmail-remote if remote qmail-rspawn qmail-inject

qmail-send qmail-lspawn

qmail-remote

qmail-local
John Mitchell

Structure of qmail
qmail-smtpd qmail-queue qmail-inject

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-queue qmail-inject

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-queue qmail-inject

qmail-send qmail-rspawn

qmail-remote

qmail-remote Delivers message to remote MTA

John Mitchell

Isolation by Unix UIDs

qmaild
qmail-smtpd qmailq qmail-queue

qmailq user who is allowed to read/write mail queue

qmail-inject

user

setuid

qmail-send qmailr qmail-rspawn

qmails

qmail-lspawn setuid user qmail-local

root root

qmailr qmail-remote

user
John Mitchell

Least privilege
qmail-smtpd qmail-inject qmail-queue

setuid

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 protected using Unix domain sockets Only ping, zygote (spawn another process) run as root Interaction: reference monitor checks permissions on intercomponent communication Least Privilege: Applications announces permission User grants access at install time
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

User process

Reference monitor

access request

?
policy

Resource

John Mitchell

Access control matrix

Objects File 1 User 1 User 2 Subjects read write File 2 write write File 3 write -

[Lampson]
File n read -

User 3

read

read

User m

read

write

read

write

read
John Mitchell

Two implementation concepts

File 1 File 2 write write read

Access control list (ACL) User 1 read Store column of matrix User 2 write with the resource User 3 Capability User holds a ticket for each resource User m Read Two variations store row of matrix with user, under OS control unforgeable ticket in user space

write

write

Access control lists are widely used, often with groups Some aspects of capability concept are used in many systems

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
User U
Process P User U Process Q User U Process R Capabilty c,d,e Process P Capabilty c,e Process Q Capabilty c Process R

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

Roles (also called 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 List only new permissions User given to each role
Guest

John Mitchell

Role-Based Access Control

Individuals Roles engineering Resources

Server 1

marketing

Server 2

human res

Server 3

Advantage: users change more frequently than roles

John Mitchell

Secure Architecture Principles

Operating Systems

John Mitchell

Unix access control

File 1 File 2 write write read

Process has user id User 2 Inherit from creating process User 3 Process can change id Restricted set of options User m Special root id Bypass access control restrictions File has access control list (ACL) Grants permission to user ids Owner, group, other

User 1

read write -

Read

write

write

John Mitchell

Unix file access control list

Each file has owner and group Permissions set by owner setid 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

Question
Owner can have fewer privileges than other What happens? Owner gets access? Owner does not?

Prioritized resolution of differences

if user = owner then owner permission else if user in group then group permission else other permission

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 calls

seteuid(newid) can set EUID to
Real ID or saved ID, regardless of current EUID Any ID, if EUID=0

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
RUID 25 ; ; exec( );

Owner 18 SetUID
program Owner 18 -rw-r--r-file Owner 25 -rw-r--r-file

; read/write ; i=getruid() setuid(i); read/write ; ;

RUID 25 EUID 18 RUID 25 EUID 25

John Mitchell

Setuid programming
Be Careful with Setuid 0 ! Root can do anything; don t get tricked Principle of least privilege change EUID when root privileges no longer needed

John Mitchell

Unix summary
Good things Some protection from most users Flexible enough to make things possible Main limitation Too tempting to use root privileges No way to assume some root privileges without all root privileges

John Mitchell

Access control in Windows

Some basic functionality similar to Unix Specify access for groups and users
Read, modify, change owner, delete

Some additional concepts Tokens Security attributes Generally More flexible than Unix Can define new permissions Can give some but not all administrator privileges
John Mitchell

Identify subject using SID

Security ID (SID) Identity (replaces UID) SID revision number 48-bit authority value variable number of Relative Identifiers (RIDs), for uniqueness Users, groups, computers, domains, domain members all have SIDs

John Mitchell

Process has set of tokens

Security context Privileges, accounts, and groups associated with the process or thread Presented as set of tokens Security Reference Monitor Uses tokens to identify the security context of a process or thread Impersonation token Used temporarily to adopt a different security context, usually of another user
John Mitchell

Object has security descriptor

Security descriptor associated with an object Specifies who can perform what actions on the object Several fields Header Descriptor revision number Control flags, attributes of the descriptor
E.g., memory layout of the descriptor

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

Access token

User: Mark Group1: Administrators Group2: Writers Revision Number Control flags Owner SID Group SID DACL Pointer SACL Pointer Deny Writers Read, Write Allow Mark Read, Write

Access request: write Action: denied User Mark requests write permission Descriptor denies permission to group Reference Monitor denies request
(DACL for access, SACL for audit and logging)

Security descriptor

Priority: Explicit Deny Explicit Allow Inherited Deny 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 of server Anonymous Token has no information about the client Identification server obtain the SIDs of client and client's privileges, but server cannot impersonate the client Impersonation server identify and impersonate the client Delegation lets server impersonate client on local, remote systems
John Mitchell

Secure Architecture Principles

Browser Isolation and Least Privilege

John Mitchell

Web browser: an analogy

Operating system
Subject: Processes
Has User ID (UID, SID) Discretionary access control

Web browser
Subject: web content (JavaScript)
Has Origin Mandatory access control

Objects
File Network

Objects
Document object model Frames Cookies / localStorage

Vulnerabilities
Untrusted programs Buffer overflow

Vulnerabilities
Cross-site scripting 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 Up to 20 processes Sandboxed One process per plugin Full privileges of browser
John Mitchell

Chromium
Communicating sandboxed components

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

John Mitchell

Design Decisions
Compatibility Sites rely on the existing browser security policy Browser is only as useful as the sites it can render Rules out more clean slate approaches Black Box Only renderer may parse HTML, JavaScript, etc. Kernel enforces coarse-grained security policy Renderer to enforces finer-grained policy decisions Minimize User Decisions
John Mitchell

Task Allocation

John Mitchell

Leverage OS Isolation
Sandbox based on four OS mechanisms
A restricted token The Windows job object The Windows desktop object Windows Vista only: 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

Summary
Security principles Isolation Principle of Least Privilege Qmail example Access Control Concepts Matrix, ACL, Capabilities OS Mechanisms Unix File system, Setuid Windows File system, Tokens, EFS Browser security architecture Isolation and least privilege example
John Mitchell