Introduction to Information Security 0368-3065, Spring 2013

Lecture 6: Process confinement (cont.), smartphone security

Eran Tromer, Roei Schuster

Slides credit: Dan Boneh and John Mitchell, Stanford

1 Improved interposition: Systrace

monitored application monitor policy file (outlook) for app

open(“etc/passwd”, “r”)

sys-call systrace gateway permit/deny OS Kernel

• Systrace only forwards monitored sys-calls to monitor (saves context switches) • Systrace resolves sym-links and replaces sys-call path arguments by full path to target • When app calls execve, monitor loads new policy file • Fast path in kernel for common/easy cases, ask userspace for complicated/rare cases 2 Systrace policy

• Sample policy file: path allow /tmp/* path deny /etc/passwd network deny all

• Specifying policy for an app is quite difficult – Systrace can auto-gen policy by learning how app behaves on “good” inputs – If policy does not cover a specific sys-call, ask user … but user has no way to decide

• Difficulty with choosing policy for specific apps (e.g. browser) is main reason this approach is not widely used

3 Userspace sandboxing: Google Native Client (NaCl)

Untrusted Browser code NPAPI HTML JavaScript

NaCl runtime • Run untrusted x86 for performance (e.g., Quake) • Two sandboxes: – Outer sandbox: restricts capabilities using system call interposition (on Linux: uses seccomp to tell the kernel to filter its system calls) – Inner sandbox: • Uses x86 to isolate application memory from one another • Restricts allowed machine code to protect the segmentation • Allows only a subset of x86; verified during loading.

4 Linux Security Modules (in-kernel)

• SELinux – Role-based user/process labels – Object labels • Identifies filesystem objects by inode and associated extended attribute (set via system policy) – Policy determines who can access what – Default policies, can be configured • Change policy and relabel filesystem • Manually relabel file system objects • AppArmor – Identified filesystem objects by path • Smack – Goal: simplicity All are Mandatory Access Control.

5 Summary

• Many sandboxing techniques: – Physical air gap, – Virtual air gap (VMMs) (later lecture) – System call interposition – Software Fault isolation (e.g., NaCl) – Application specific (e.g. Javascript in browser)

• Often complete isolation is inappropriate – Apps need to communicate through regulated interfaces

• Hardest aspect of sandboxing: – Specifying policy: what can apps do and not do

6 Continued to: Introduction to Mobile Platform Security (separate file)

7 7