Update on MIT-LL Integration Bill Harris and Rich Joiner

Schedule: JAM Deliverables: ◦ Policy for Secure Note application ◦ JAM weaver ◦ Chrome browser modified for enforcement Weaver/policy delivery planned for 9/3. Enforcement delivery planned for 9/10.

Application: Secure Note Written by MIT-LL crew Code comprises ◦ SNote application logic ◦ Midori UI library ◦ Google AES encryption library

Policy Read-only, write-once for display elements Write-only, read-once for input elements

Policy state machine a: set(%x.textContent) && %x.className === “non-editable” 0 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 e|f|g|h c|d

Policy specification 0,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 Weaver To 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

Enforcement Checks are evaluated at runtime in an isolated forked process JavaScript 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 System 1. Overview of CapWeave usage 2. Sketch of our approach 3. Discuss deliverables, requirements

CapWeave Usage CRASH server generates web content by 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 content

php Requirements 1. Whitelist of system libs: read-only 2. php, MediaWiki config. files: read-only 3. MediaWiki php scripts: read-only 4. MediaWiki skin files: read-only 5. Scratch directories (e.g., /tmp): read- write 6. Sockets to database server: read-write

CapWeave in the CRASH System 1. 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 System 1. Overview of CapWeave usage 2. Sketch of our approach 3. Discuss deliverables, requirements

Requirements Decision functions for each requirement E.g.: ◦ int is_whitelist_sys_lib(char* path) ◦ int is_mediawiki_config(char* path)

Deliverables Policy regex text file Capsicum 9 VMWare image with weaved php ◦ Capsicum team recently posted a working Capsicum VMWare image

Extra Slides