Update on MIT-LL IntegrationBill Harris and Rich Joiner

Schedule: JAMDeliverables:

◦Policy for Secure Note application◦JAM weaver◦Chrome browser modified for

enforcementWeaver/policy delivery planned

for 9/3.Enforcement delivery planned for

9/10.

Application: Secure NoteWritten by MIT-LL crewCode comprises

◦SNote application logic◦Midori UI library◦Google AES encryption library

http://snote/SNoteSwindler.html

PolicyRead-only, write-once for display

elementsWrite-only, read-once for input

elements

Policy state machinea: set(%x.textContent) && %x.className === “non-editable”

0

1-1

f: set(%x.textContent) && %x.className === “read-only”

b: set(%x.innerHTML) && %x.className === “non-editable”

e: set(%x.textContent) && %x.className === “read-only”

c: get(%x.textContent) && %x.className === “destructive-read”

h: get(%x.textContent) && %x.className === “write-only”

d: get(%x.innerHTML) && %x.className === “destructive-read”

g: get(%x.textContent) && %x.className === “write-only”

2

a|b a|b

e|f|g|h

c|d c|d

Policy specification0,2: set(%x.textContent) && %x.className === "non-editable"2,-1: set(%x.innerHTML) && %x.className === "non-editable"0,2: set(%x.innerHTML) && %x.className === "non-editable"2,-1: set(%x.textContent) && %x.className === "non-editable"0,-1: set(%x.innerHTML) && %x.className === "read-only“0,-1: set(%x.textContent) && %x.className === "read-only"0,1: get(%x.textContent) && %x.className === "destructive-read"1,-1: get(%x.textContent) && %x.className === "destructive-read"0,1: get(%x.innerHTML) && %x.className === "destructive-read"1,-1: get(%x.innerHTML) && %x.className === "destructive-read"0,-1: get(%x.textContent) && %x.className === "write-only"0,-1: get(%x.innerHTML) && %x.className === "write-only"

JAM WeaverTo be delivered as a virtual machine

image◦Compiled JAM binaries◦Test cases◦Script to download and install

dependencies◦Documentation

Policy specification language General usage Current limitations

EnforcementChecks are evaluated at runtime

in an isolated forked processJavaScript native functions added

to trigger the fork and evaluate policy predicates

To be delivered as a stand-alone Chrome binary built on FreeBSD 9.

CapWeave in the CRASH System1. Overview of CapWeave usage

2. Sketch of our approach

3. Discuss deliverables, requirements

CapWeave UsageCRASH server generates web

contentby running php scripts

CRASH team defines policy for all php scripts

CRASH team applies CapWeave to rewrite php interpreter to enforce policy

php workflow

php

filesystem

web_script.cgi

web conten

t

php Requirements1. Whitelist of system libs: read-

only2. php, MediaWiki config. files:

read-only3. MediaWiki php scripts: read-only4. MediaWiki skin files: read-only5. Scratch directories (e.g., /tmp):

read-write6. Sockets to database server:

read-write

CapWeave in the CRASH System1. Overview of CapWeave usage

2. Sketch of our approach

3. Discuss deliverables, requirements

UW Challenges

1. Express requirements in policy language

2. Rewrite/weave the php to satisfy the policy

int shim_open(char* path, int mode) { int fd = open(path, mode); if (sat_req_1(path)) { cw_act(0); } if (sat_req_2(path)) { … } return fd;}

A Shim for open()

Requirement 1 Policy

(* requirement 1 policy: *)let not_fd_read = … in any_act* . (cw_act 0) . (any_prog_act with not_fd_read)

int shim_open(char* path, int mode) { int fd = open(path, mode); if (sat_req_1(path)) { cw_act(0); lc_limitfd(fd, CAP_READ); } if (sat_req_2(path)) { … } return fd;}

A Weaved shim_open()

CapWeave in the CRASH System1. Overview of CapWeave usage

2. Sketch of our approach

3. Discuss deliverables, requirements

RequirementsDecision functions for each

requirement

E.g.:◦int is_whitelist_sys_lib(char* path)◦int is_mediawiki_config(char* path)

DeliverablesPolicy regex text file

Capsicum 9 VMWare image with weaved php◦Capsicum team recently posted a

workingCapsicum VMWare image

Extra Slides