Introduction to Information Security

Transcription

1 Introduction to Information Security , Spring 2013 Lecture 5: Information flow control (cont.), process confinement Eran Tromer 1 Slides credit: Dan Boneh and John Mitchell, Stanford Max Krohn, MIT Ian Goldberg and Urs Hengartner, University of Waterloo

2 Information Flow Control example Alice s Data Bob s Data DB Alice s Data Alice s Data Gateway 1. Data tracking 2. Isolated declassification 4 4

3 Information Flow Control at the Process Level Goal: track which secrets a process has seen Mechanism: each process gets a secrecy label Label summarizes which categories of data a process is assumed to have seen. Examples: { Financial Reports } label { HR Documents } { Financial Reports and HR Documents } tag 5

4 Distributed Information Flow Control at the Process Level Goals: Let processes define new tags (create new compartments ) and have then enforce Controlled declassification Mechanism: Each process gets a declassification label Each process can get create a new tag Creating a new tag adds it to that process s declassification label Declassification capabilities (tags) can be delegated to other processes 6

5 7 DIFC, tags and labels by example (1) Process p S p = {} D p = {} Secrecy label Declassification label Universe of Tags: Finance SecretProjects Legal

6 8 DIFC, tags and labels by example (2) Process p S p = {Finance} D p = {} Universe of tags: change_label({finance}); Any process can add any tag to its label. (OK if there s a gatekeeper at outout. Alternative: require specific permissions.) Finance SecretProjects Legal

7 9 DIFC, tags and labels by example (3) Process p S p = {Finance} D p = {} change_label({finance}); change_label({}); Cannot remove arbitrary tags from label Universe of tags: Finance SecretProjects Legal

8 10 DIFC, tags and labels by example (4) Process p S p = {Finance} D p = { HR } change_label({finance}); tag_t HR = create_tag(); DIFC Rule: A process can create a new tag; gets ability to declassify it. Universe of tags: HR Legal Finance SecretProjects

9 11 DIFC, tags and labels by example (5) Process p S p = {Finance,HR} D p = { HR } change_label({finance}); tag_t HR = create_tag(); change_label({finance,hr}); Can add tags. Universe of tags: HR Legal Finance SecretProjects

10 12 DIFC, tags and labels by example (6) Process p S p = {Finance} D p = { HR } change_label({finance}); tag_t HR = create_tag(); change_label({finance,hr}); change_label({finance}); Declassification allowed because HR Universe of tags: HR Legal Finance SecretProjects in D p

11 13 DIFC, tags and labels by example (7) Process p S p = {Finance} D p = { HR } Universe of tags: change_label({finance}); tag_t HR = create_tag(); change_label({finance,hr}); change_label({finance}); send_declass_cap(q,{hr}); HR Finance SecretProjects Add HR to D q of process Legal q

12 Alice s Data p Alice s Data q DIFC OS declassi fier S q = {} S p = {a} S q = {a} S d = {a} D d = {a} KERNEL 14

13 Communication Rule Process p Process q S p = { HR } S q = { HR, Finance } p can send to q iff S p S q 15

14 Question: What interface should the kernel expose to applications? Easier question than is my OS implementation secure Easy to get it wrong! 16

15 Approach 1: Taint propegation / Floating Labels [IX,Asbestos] p S {} p = {a} S q = {a} q KERNEL 17

16 Floaters Leaks Data Alice s Data attacker b 0 S = {} Leak file S = {a} S = {a} {} b 1 S = {a} {} S = {} 1001 b 2 S = {a} {} b 3 S = {} 18

17 Approach 2: Set Your Own [HiStar/Flume] p S p = {a} D p = {a} S q = {} D q = {} q KERNEL 19

18 Approach 2: Set Your Own [HiStar/Flume] p S p = {a} D p = {a} S q = {a} D q = {} q KERNEL Rule: S p S q necessary precondition for send 20

19 Case study: Flume Goal: User-level implementation apt-get install flume Approach: System Call Delegation [Ostia by Garfinkel et al, 2003] Use Linux 2.6 (or OpenBSD 3.9) 21

20 System Call Delegation open( /hr/layoffplans, O_RDONLY); Web App glibc Linux Kernel Layoff Plans 22

21 System Call Delegation open( /hr/layoffplans, O_RDONLY); Web App Flume Libc Flume Reference Monitor Linux Kernel Layoff Plans 23

22 System Calls IPC: read, write, select Process management: fork, exit, getpid DIFC: create tag, change label, fetch label, send capabilities, receive capabilities 24

23 How To Prove Security Property: Noninterference 25

24 Noninterference [Goguen & Meseguer 82] Experiment #1: p q S p = {a} S q = {} Experiment #2: HIGH = LOW p S p = {a} S q = {} q 26

25 How To Prove Security (cont.) 7 27 Property: Noninterference Process Algebra model for a DIFC OS Communicating Sequential Processes (CSP) Prove that the model fits the definition Consider any possible system (with arbitrary user applications) Induction over all possible sequences of moves a system can make (i.e., traces) At each step, case-by-case analysis of all system calls in the interface. Prove that the code fits the model

26 28 Results on Flume Allows adoption of Unix software? 1,000 LOC launcher/declassifier 1,000 out of 100,000 LOC in MoinMoin changed Python interpreter, Apache, unchanged Solves security vulnerabilities? Without our knowing, we inherited two ACL bypass bugs from MoinMoin Both are not exploitable in Flume s MoinMoin Performance? Performs within a factor of 2 of the original on read and write benchmarks Example App: MoinMoin Wiki

27 What are we trusting? Proof of noninterference Platform Hardware Virtual machine manager Kernel Reference monitor Declassifier Human decisions Covert channels Physical access User authentication The code owning each label 29 29

28 Practical barriers to deployment of Information Flow Control systems Programming model confuses programmers Lack of support: Applications Libraries Operating systems People don t care about security until it's too late 30 30

29 Quantitative information flow control Quantify how much information (#bits) is leaking from (secret) inputs to outputs Approach: dynamic analysis (extended tainting) followed by flow graph analysis Example: battleship online game 31 31

30 32 Process Confinement

31 Running untrusted code We often need to run buggy/unstrusted code: Programs from untrusted Internet sites: toolbars, viewers, codecs for media players, rich content, secure banking Old or insecure applications: ghostview, Outlook Legacy daemons: sendmail, bind Honeypots Goal: if application misbehaves, kill it 33

32 Confinement Confinement: ensure application does not deviate from pre-approved behavior Can be implemented at many levels: Hardware: isolated hardware ( air gap ) Difficult to manage Sufficient? Virtual machines: isolate OSs on single hardware System call interposition: Isolates a process in a single operating system Isolating threads sharing same address space: Software Fault Isolation (SFI), e.g., Google Native Code Interpreters for non-native code JavaScript, JVM,.NET CLR 34

33 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 35

34 A simple example: chroot Often used for guest accounts on ftp sites To use do: (must be root) # chroot /home/guest root dir / is now /home/guest # su guest EUID set to guest Now /home/guest is added to file system accesses for applications in jail open( /etc/passwd, r ) open( /home/guest/etc/passwd, r ) 36 application cannot access files outside of jail

35 Jailkit Problem: all utility programs (ls, ps, vi) must live inside jail 37 jailkit project: auto builds files, libs, and dirs needed in jail environment 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 Restricts only filesystem access. Unaffected: Network access Inter-process communication Devices, users, (see later)

36 Escaping from jails Early escapes: relative paths open(../../etc/passwd, r ) open( /tmp/guest/../../etc/passwd, r ) chroot should only be executable by root otherwise jailed app can do: create dummy file /aaa/etc/passwd run chroot /aaa run su root to become root (bug in Ultrix 4.0) 38

37 39 Many ways to escape jail as root Create device that lets you access raw disk mknod sda b 8 0 cat malicious-boot-record > sda Send signals to non chrooted process Reboot system Bind to privileged ports (e.g., usurp incoming packets to TCP port 80)

38 40 FreeBSD jail Stronger mechanism than simple chroot To run: jail jail-path hostname IP-addr cmd calls hardened chroot (no../../ escape) can only bind to sockets with specified IP address and authorized ports can only communicate with process inside jail root is limited, e.g. cannot load kernel modules

39 Problems with chroot and jail Coarse policies: All-or-nothing access to file system Inappropriate for apps like web browser Needs read access to files outside jail (e.g. for sending attachments in gmail) Do not prevent malicious apps from: Accessing network and messing with other machines Trying to crash host OS 41

40 42 System call interposition: a better approach to confinement

41 43 System call interposition Observation: to damage host system (i.e. make persistent changes) app must make system calls To delete/overwrite files: unlink, open, write To do network attacks: socket, bind, connect, send Monitor app system calls and block unauthorized calls Implementation options: Completely kernel space (e.g. GSWTK) Completely user space Capturing system calls via dynamic loader (LD_PRELOAD) Dynamic binary rewriting (program shepherding) Hybrid (e.g. Systrace)

42 Initial implementation (Janus) Linux ptrace: process tracing tracing process calls: ptrace (, pid_t pid, ) and wakes up when pid makes sys call. monitored application (Outlook) monitor user space open( /etc/passwd, r ) OS Kernel Monitor kills application if request is disallowed 44

43 45 Complications Monitor must maintain all OS state associated with app current-working-dir (CWD), UID, EUID, GID Whenever app does cd path monitor must also update its CWD otherwise: relative path requests interpreted incorrectly If app forks, monitor must also fork Forked monitor monitors forked app Monitor must stay alive as long as the program runs Unexpected/subtle OS features: file description passing, core dumps write to files, process-specific views (chroot, /proc/self)

44 Problems with ptrace ptrace is too coarse for this application Trace all system calls or none e.g. no need to trace close system call Monitor cannot abort sys-call without killing app Security problems: race conditions Example: symlink: me -> mydata.dat time proc 1: open( me ) monitor checks and authorizes proc 2: me -> /etc/passwd OS executes open( me ) not atomic Classic TOCTOU bug: time-of-check / time-of-use 46