Faculty of Computer Science Institute for System Architecture, Operating Systems Group Information Flow Control for Standard OS Abstractions Dresden, Maxwell Krohn, M. Frans Kaashoek et. al. (presented by Stefan Kalkowski)

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 2 von 34 What is it about? Decentralized Information Flow –A. Myers and B. Liskov (MIT) '00 –related to Originator Controlled Access Control Graubart '89

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 3 von 34 What is it about? Decentralized Information Flow –A. Myers and B. Liskov (MIT) '00 –related to Originator Controlled Access Control Graubart '89 Solution to Declassification Problem –centralized trusted subjects –in mutual distrust environment they are useless –decentralize authority for declassifying

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 4 von 34 Declassification Problem Secrecy rule

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 5 von 34 Declassification Problem Integrity rule

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 6 von 34 Idea behind DIFC Object creator organizes policy Alic e

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 7 von 34 Idea behind DIFC Object creator organizes policy creates Alic e curious object

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 8 von 34 Idea behind DIFC spread upgrading and downgrading capabilities while object creation creates Alicecurious object Activitie s

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 9 von 34 DIFC – basic approaches Language based: Myer, Liskov developed Java extension called JIF

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 10 von 34 DIFC – basic approaches Language based: Myer, Liskov developed Java extension called JIF OS based: –AsbestOS (MIT) – experiment from the scratch –HiStar (Stanford) – IFC-kernel with UNIX layer –Flume (MIT) – do it in UNIX like systems

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 11 von 34 Flume Abstractions Tags and Labels for integrity and secrecy Process Integrity Secrecy Labe l Tag s

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 12 von 34 Flume Secrecy Rules Example: process p with I p and S p and some object o with tag t (I p, S p є Label)

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 13 von 34 Flume Secrecy Rules Example: process p with I p and S p and some object o with tag t (I p, S p є Label) The following rules apply: I.if p reads o, then t є S p

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 14 von 34 Flume Secrecy Rules Example: process p with I p and S p and some object o with tag t (I p, S p є Label) The following rules apply: I.if p reads o, then t є S p II.if p writes to q and t є S p, then t є S q

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 15 von 34 Flume Secrecy Rules Example: process p with I p and S p and some object o with tag t (I p, S p є Label) The following rules apply: I.if p reads o, then t є S p II.if p writes to q and t є S p, then t є S q III.p cannot remove t from S p

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 16 von 34 Flume Secrecy Rules Example: process p with I p and S p and some object o with tag t (I p, S p є Label) The following rules apply: I.if p reads o, then t є S p II.if p writes to q and t є S p, then t є S q III.p cannot remove t from S p IV.if S p ≠{}, then p cannot transmit information over uncontrolled channels

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 17 von 34 Flume Integrity Rules I.if p modifies o, then t є I p

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 18 von 34 Flume Integrity Rules I.if p modifies o, then t є I p II.if t є I p, then p can only read from files and processes with t integrity

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 19 von 34 Flume Integrity Rules I.if p modifies o, then t є I p II.if t є I p, then p can only read from objects and processes with t integrity III.p cannot add t to I p

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 20 von 34 Flume Integrity Rules I.if p modifies o, then t є I p II.if t є I p, then p can only read from objects and processes with t integrity III.p cannot add t to I p IV.if I p ≠{}, then p cannot accept input from uncontrolled channels

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 21 von 34 Capabilities for label changes Allocation of tags determines the distribution of add and remove capabilities in the system Beside the local capability set of a process, there is one global for all Tag capabilities can be spread between processes

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 22 von 34 Flume's safety model Label changes have to be done explicitly by the process itself and only if it has proper capabilities

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 23 von 34 Flume's safety model Label changes have to be done explicitly by the process itself and only if it has proper capabilities p can send a message to q only if S p is in S q and I q is in I p

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 24 von 34 Flume's safety model Label changes have to be done explicitly by the process itself and only if it has proper capabilities p can send a message to q only if S p is in S q and I q is in I p any data sink or source outside of Flume's model is represented as a process r with S r = I r = {}

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 25 von 34 Flume's safety model Label changes have to be done explicitly by the process itself and only if it has proper capabilities p can send a message to q only if S p is in S q and I q is in I p any data sink or source outside of Flume's model is represented as a process r with S r = I r = {} files are processes with immutable secrecy and integrity labels

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 26 von 34 Flume in practice: Endpoints Endpoints are assigned to file-descriptors and inherit the labels of the process Processes can configure their endpoints labels accordingly to the communication that has to be done pipe endpoints are mutable, file endpoints are immutable label changes that break safety of an immutable endpoint are forbidden

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 27 von 34 Linux implementation

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 28 von 34 Confined Processes using LSM hooks for intercepting syscalls mediated to user-level reference monitor adapted C-library calls RM directly (dependent on syscall) some calls are simply forbidden (like fork) spawn creates a new confined process with the labels of the “parent” spawner process prepares the new process, forks it, enables LSM, closes file-descriptors...

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 29 von 34 IPC Reference monitor proxies all traffic of a pipe RM buffers messages and evaluates the whole processes label state (including endpoints) If communication is only allowed one way, RM silently drops messages from diligent producer, which floods the buffer using Unix domain sockets is analogous to using files

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 30 von 34 Files and persistence Restrictions: –writable file-descriptors are implicitly readable –files have an additional write-protect set containing tags Processes cannot create files within directories, that are less secret than themselves Tag registry maintains login tokens, capability groups and extended file attributes

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 31 von 34 Evaluation Detected two known and one unknown vulnerabilities within Wiki example application

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 32 von 34 Evaluation Detected two known and one unknown vulnerabilities within Wiki example application Additional complexity: –Flume's TCB: LOC (mostly user-level) –Wiki-App: LOC and LOC changed

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 33 von 34 Evaluation Detected two known and one unknown vulnerabilities within Wiki example application Additional complexity: –Flume's TCB: LOC (mostly user-level) –Wiki-App: LOC and LOC changed Overall performance overhead:

TU Dresden, Information Flow Control for Standard OS Abstractions Slide 34 von 34 Questions Do we need DIFC within legacy operating systems, or are there more urgent security defects? Is the effort to make Unix Apps DIFC compliant really lesser than porting them to new OSes? Is it easy to apply that label model to L4env or Bastei?