1. Update on MIT-LL Integration Bill Harris and Rich Joiner

2. 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.

3. Application: Secure Note Written by MIT-LL crew Code comprises ◦ SNote application logic ◦ Midori UI library ◦ Google AES encryption library http://snote/SNoteSwindler.html

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

5. 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

6. 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"

7. 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

9. 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.

11. CapWeave in the CRASH System 1. Overview of CapWeave usage 2. Sketch of our approach 3. Discuss deliverables, requirements

15. 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

16. php workflow php filesystem web_script.cgi web content

17. 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

18. CapWeave in the CRASH System 1. Overview of CapWeave usage 2. Sketch of our approach 3. Discuss deliverables, requirements

19. UW Challenges 1. Express requirements in policy language 2. Rewrite/weave the php to satisfy the policy

20. 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()

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

22. 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()

23. CapWeave in the CRASH System 1. Overview of CapWeave usage 2. Sketch of our approach 3. Discuss deliverables, requirements

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

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

26. Extra Slides