Isola&on: The Confinement Principle
Isola&on: The Confinement Principle
Isola&on: The Confinement Principle
The confinement
principle
Original slides were created by Prof. Dan Boneh
1
Running untrusted code
We often need to run buggy/unstrusted code:
– programs from untrusted Internet sites:
• apps, extensions, plug-ins, codecs for media player
– honeypots
app 1 app 2
app1 app2
OS1 OS2
Virtual Machine Monitor (VMM)
4
Approach: confinement
Confinement: ensure misbehaving app cannot harm rest of system
process 1
process 2
Opera&ng System 5
Approach: confinement
Confinement: ensure misbehaving app cannot harm rest of system
6
Implementing confinement
Key component: reference monitor
– Mediates requests from applications
• Implements protection policy
• Enforces isolation and confinement
– Must always be invoked:
• Every application request must be mediated
– Tamperproof:
• Reference monitor cannot be killed
• … or if killed, then monitored process is killed too
– Small enough to be analyzed and validated
7
A old example: chroot
• Often used for “guest” accounts on ftp sites
• jailkit project: auto builds files, libs, and dirs needed in jail env
• jk_init: creates jail environment
• jk_check: checks jail env for security problems
• checks for any modified programs,
• checks for world writable directories, etc.
• jk_lsh: restricted shell to be used inside jail
• Reboot system
13
Problems with chroot and jail
Coarse policies:
– All or nothing access to parts of file system
– Inappropriate for apps like a web browser
• Needs read access to files outside jail
(e.g. for sending attachments in Gmail)
System Call
Interposi&on
15
System call interposition
Observation: to damage host system (e.g. persistent changes)
app must make system calls:
– To delete/overwrite files: unlink, open, write
– To do network attacks: socket, bind, connect, send
Implementation options:
– Completely kernel space (e.g. GSWTK)
– Completely user space (e.g. program shepherding)
– Hybrid (e.g. Systrace) 16
Initial implementation (Janus) [GWTB’96]
open(“/etc/passwd”, “r”)
OS Kernel
Monitor kills application if request is disallowed 17
Complications cd(“/tmp”)
open(“passwd”, “r”)
• If app forks, monitor must also fork
cd(“/etc”)
– forked monitor monitors forked app open(“passwd”, “r”)
• If monitor crashes, app must be killed
sys-call systrace
gateway
permit/deny OS Kernel
• systrace only forwards monitored sys-calls to monitor (efficiency)
A delega&on architecture:
user space
monitored
agent
applica1on policy file
open(“etc/passwd”, “r”) for app
OS Kernel 21
Os&a: a delega&on architecture [GPR’04]
• Monitored app disallowed from making monitored sys calls
– Minimal kernel change (… but app can call close() itself )
• Two sandboxes:
– outer sandbox: restricts capabilities using system call interposition
Isola&on via
Virtual Machines
25
Virtual Machines
VM2 VM1
Apps Apps
Guest OS 2 Guest OS 1
Virtual Machine Monitor (VMM)
Host OS
Hardware
Example: NSA NetTop
single HW platform used for both classified and unclassified data 26
Why so popular now?
VMs in the 1960’s:
– Few computers, lots of users
– VMs allow many users to shares a single computer
Classified VM Public VM
malware
secret covert
doc
channel listener
VMM
29
An example covert channel
Both VMs use the same underlying hardware
At 1:00am listener does CPU intensive calc. and measures completion time
b=1 ⇔ completion-time > threshold
32
Intrusion Detection / Anti-virus
Runs as part of OS kernel and user space process
– Kernel root kit can shutdown protection system
– Common practice for modern malware
malware Guest OS
IDS VMM
Hardware
34
Sample checks
Stealth root-kit malware:
– Creates processes that are invisible to “ps”
– Opens sockets that are invisible to “netstat”
Subvir&ng VM
Isola&on
37
Subvirt [King et al. 2006]
Virus idea:
– Once on victim machine, install a malicious VMM
– Virus hides in VMM
– Invisible to virus detector running inside VM
anti-virus
anti-virus
⇒ OS
OS VMM and virus
HW HW 38
The MATRIX
39
40
VM Based Malware (blue pill virus)
• VMBR: a virus that installs a malicious VMM (hypervisor)
Applications:
44
Isola&on
Sohware Fault
Isola&on
45
Software Fault Isolation [Whabe et al., 1993]
app #1 app #2
Solu1on:
jmp guard must ensure [addr] does not bypass load guard
Cross domain calls
caller callee
domain domain
call stub draw:
call draw
return
br addr br addr
br addr ret stub br addr
br addr br addr
• Only stubs allowed to make cross-domain jumps
• Jump table contains allowed exit points
– Addresses are hard coded, read-only segment 51
SFI Summary
• Shared memory: use virtual memory hardware
– map same physical page to two segments in addr space
• Performance
– Usually good: mpeg_play, 4% slowdown
54