Chapter 15. Information Flow

Slides:



Advertisements
Similar presentations
Information Flow and Covert Channels November, 2006.
Advertisements

Continuing Abstract Interpretation We have seen: 1.How to compile abstract syntax trees into control-flow graphs 2.Lattices, as structures that describe.
Chapter 9 Code optimization Section 0 overview 1.Position of code optimizer 2.Purpose of code optimizer to get better efficiency –Run faster –Take less.
Ch. 7 Process Synchronization (1/2) I Background F Producer - Consumer process :  Compiler, Assembler, Loader, · · · · · · F Bounded buffer.
© Copyright 1992–2004 by Deitel & Associates, Inc. and Pearson Education Inc. All Rights Reserved. 1 Chapter 4 – C Program Control Outline 4.1Introduction.
1 Chapter 7: Runtime Environments. int * larger (int a, int b) { if (a > b) return &a; //wrong else return &b; //wrong } int * larger (int *a, int *b)
1 Information Flow CSSE 490 Computer Security Mark Ardis, Rose-Hulman Institute April 22, 2004.
Remote Procedure Call in SR Programming Language By Tze-Kin Tsang 3/20/2000.
CS 536 Spring Global Optimizations Lecture 23.
C Lecture Notes 1 Program Control (Cont...). C Lecture Notes 2 4.8The do / while Repetition Structure The do / while repetition structure –Similar to.
4/25/08Prof. Hilfinger CS164 Lecture 371 Global Optimization Lecture 37 (From notes by R. Bodik & G. Necula)
1 Pertemuan 20 Run-Time Environment Matakuliah: T0174 / Teknik Kompilasi Tahun: 2005 Versi: 1/6.
November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #15-1 Chapter 15: Information Flow Definitions Compiler-based mechanisms Execution-based.
July 1, 2004Computer Security: Art and Science © Matt Bishop Slide #16-1 Chapter 16: Information Flow Entropy and analysis Non-lattice information.
Data Flow Analysis Compiler Design Nov. 8, 2005.
Prof. Fateman CS 164 Lecture 221 Global Optimization Lecture 22.
Objectives You should be able to describe:
Prof. Bodik CS 164 Lecture 16, Fall Global Optimization Lecture 16.
Fundamentals of Python: From First Programs Through Data Structures
Fundamentals of C and C++ Programming Control Structures and Functions.
Chapter 4: Decision Making with Control Structures and Statements JavaScript - Introductory.
Lecture 4 C Program Control Acknowledgment The notes are adapted from those provided by Deitel & Associates, Inc. and Pearson Education Inc.
1 4.8The do/while Repetition Structure The do/while repetition structure –Similar to the while structure –Condition for repetition tested after the body.
Compiler Construction
CSC 3210 Computer Organization and Programming Chapter 1 THE COMPUTER D.M. Rasanjalee Himali.
CPS120: Introduction to Computer Science Decision Making in Programs.
COMPUTER PROGRAMMING. Iteration structures (loops) There may be a situation when you need to execute a block of code several number of times. In general,
 2000 Prentice Hall, Inc. All rights reserved. 1 Chapter 4 - Program Control Outline 4.1Introduction 4.2The Essentials of Repetition 4.3Counter-Controlled.
A Lattice Model of Secure Information Flow By Dorothy E. Denning Presented by Drayton Benner March 22, 2000.
LECTURE # 8 : REPETITION STATEMENTS By Mr. Ali Edan.
55:032 - Intro. to Digital DesignPage 1 VHDL and Processes Defining Sequential Circuit Behavior.
1 Chapter 11 Global Properties (Distributed Termination)
Operational Semantics Mooly Sagiv Reference: Semantics with Applications Chapter 2 H. Nielson and F. Nielson
Operational Semantics Mooly Sagiv Reference: Semantics with Applications Chapter 2 H. Nielson and F. Nielson
C Program Control September 15, OBJECTIVES The essentials of counter-controlled repetition. To use the for and do...while repetition statements.
Chapter 4 – C Program Control
Chapter 6: Loops.
REPETITION CONTROL STRUCTURE
Compilers Principles, Techniques, & Tools Taught by Jing Zhang
Principles of programming languages 4: Parameter passing, Scope rules
Algorithm Analysis CSE 2011 Winter September 2018.
User input We’ve seen how to use the standard output buffer
Stacks Chapter 4.
Chapter 8: Control Structures
Flow of Control.
6.001 SICP Stacks and recursion
Computation.
Chapter 9 :: Subroutines and Control Abstraction
Arrays, For loop While loop Do while loop
MSIS 655 Advanced Business Applications Programming
Flow of Control.
Topics Introduction to File Input and Output
CMPE 152: Compiler Design October 4 Class Meeting
Structured Program
Chapter 4 - Program Control
Chapter 16: Information Flow
Flow of Control.
Chapter 6 Control Statements: Part 2
Statement-Level Control Structures
Optimizations using SSA
Data Flow Analysis Compiler Design
UNIT V Run Time Environments.
Chapter8: Statement-Level Control Structures April 9, 2019
Flow of Control.
The structure of programming
Information Flow.
Computer Security: Art and Science, 2nd Edition
ECE 103 Engineering Programming Chapter 18 Iteration
Chapter 4 - Program Control
Topics Introduction to File Input and Output
Presentation transcript:

Chapter 15. Information Flow 2012. 10. 31 이수영

Contents 15.1 Basics and Background 15.2 Compiler-Based Mechanisms 15.3 Execution-Based Mechanisms

Basics and Background BLP Model Lattice-based information flow policy Given two compartments A and B, information can flow from an object in A to a subject in B if and only if B dominates A Let x be a variable in a program. The notation x refers to the information flow class of x Def. 15-1 The command sequence c causes a flow of information from x to y if, after execution of c, some information about the value of x before c was executed can be deduced from the value of y after c was executed.

Basics and Background Examples x := y + z; 0 ≤ y ≤ 7, equal probability z = 1 with prob. 1/2, z = 2 or 3 with prob. 1/4 each If you know final value of x, initial value of y can have at most 3 values, so information flows from y to x if x = 1 then y := 0; else y := 1; x, y equally likely to be either 0 or 1 But if x = 1 then y = 0, and vice versa, so value of y depends on x So information flowed from x to y

Basics and Background Def. 15-2 An implicit flow of information occurs when information flows from x to y without an explicit assignment of the form y := f(x), where f(x) is an arithmetic expression with the variable x x means class of x x ≤ y means information can flow from an element in class of x to an element in class of y

Compiler-Based Mechanisms Detect unauthorized information flows in a program during compilation Not precise If a flow could violate policy (but may not), it is unauthorized But secure No unauthorized path along which information could flow remains undetected Def. 15-3 A set of statements is certified with respect to an information flow policy if the information flow within that set of statements does not violate the policy Example if x = 1 then y := a; else y := b; Info flows from x and a to y, or from x and b to y Certified only if x ≤ y and a ≤ y and b ≤ y

Compiler-Based Mechanisms Declarations x: int class { A, B } x is an integer variable with security class at least lub{A, B}, so lub{A, B} ≤ x lub = least upper bound, glb = greatest lower bound Distinguished classes Low, High Low : greatest lower bound of the lattice High : least upper bound of the lattice Constants are always Low Input Parameters ip: type class {ip} Output Parameters op: type class {r1, …, rn} ri is class of ith input or input/output argument

Compiler-Based Mechanisms Declarations (cont.) Example proc sum(x: int class { A }; var out: int class { A, B }); begin out := out + x; end; Require x ≤ out and out ≤ out Array Elements … := a[i] Value of i, a[i] both affect result, so class is lub{a[i], i} a[i] := … Only value of a[i] affected, so class is a[i]

Compiler-Based Mechanisms Assignment Statements y := f(x1, …, xn) lub{x1, …, xn} ≤ y Example x := y + z; Information flows from y, z to x, so this requires lub{y, z} ≤ x Compound Statements S1; … Sn; S1 ... Sn are secure x := y + z; a := b * c – x; lub{y, z} ≤ x and lub{b, c, x} ≤ a

Compiler-Based Mechanisms Conditional Statements if f(x1, …, xn) then S1; else S2; end; S1 secure S2 secure lub{x1, …, xn} ≤ glb{y | y target of assignment in S1, S2} Example if x + y < z then a := b; else d := b * c – x; end; lub{x, y, z} ≤ glb{ a, d}

Compiler-Based Mechanisms Iterative Statements while f(x1, …, xn) do S; Iterative statement terminates S secure lub{x1, …, xn} ≤ glb{y | y target of assignment in S} Example while i < n do begin a[i] := b[i]; i := i + 1; end; Loop terminates first statement is secure if lub{i, b[i]} ≤ a[i] second statement is secure because i ≤ i lub{i, n} ≤ glb{a[i], i} Thus iterative statements is secure if lub{b[i], i, n} ≤ glb{a[i], i}

Compiler-Based Mechanisms Goto Statements Def. 15-4 A basic block is a sequence of statements in a program that has one entry point and one exit point Example proc transmatrix(x: array [1..10][1..10] of int class { x }; var y: array [1..10][1..10] of int class { y } ); var i, j: int class { tmp }; begin i := 1; (* b1 *) l2: if i > 10 goto l7; (* b2 *) j := 1; (* b3 *) l4: if j > 10 then goto l6; (* b4 *) y[j][i] := x[i][j]; j := j + 1; goto l4; (* b5 *) l6: i := i + 1; goto l2; (* b6 *) l7: (* b7 *) end;

Compiler-Based Mechanisms Goto Statements (cont.) Control flow graph

Compiler-Based Mechanisms Goto Statements (cont.) Def. 15-5 An immediate forward dominator of a basic block b (written IFD(b)) is the first block that lies on all paths of execution that pass through b Example IFD(b1) = b2 one path IFD(b2) = b7 b2->b7 or b2->b3->b6->b2->b7 IFD(b3) = b4 one path IFD(b4) = b6 b4->b6 or b4->b5->b6 IFD(b5) = b4 one path IFD(b6) = b2 one path

Compiler-Based Mechanisms Goto Statements (cont.) Let Bi be the set of blocks along an execution path from bi to IFD(bi) Let xi1, ..., xin be the set of variables in the expression that selects the execution path containing the blocks in Bi The requirements for the program's information flows to be secure are All statements in each basic block secure lub{xi1, ..., xin} ≤ glb{y | y is the target of an assignment in Bi }

Compiler-Based Mechanisms Goto Statements (cont.) Example b1: Low ≤ i b3: Low ≤ j b6: lub{Low, i} ≤ i b5: lub{x[i][j], i, j} ≤ y[j][i]; j ≤ j => lub{x[i][j], i, j} ≤ y[j][i] => lub{x, i} ≤ y B2 = {b3, b4, b5, b6} Assignments to i, j, y[j][i]; conditional is i ≤ 10 => i ≤ glb{i, j, y[j][i]} => i ≤ y B4 = {b5} Assignments to j, y[j][i]; conditional is j ≤ 10 => j ≤ glb{j, y[j][i]} => i ≤ y Combine lub{x, i} ≤ y; i ≤ y; i ≤ y => lub{x, i} ≤ y

Compiler-Based Mechanisms Procedure Calls proc procname(i1, …, im: int; var o1, …, on: int) begin S end; Let x1, ..., xm and y1, ..., yn be the actual input and input/output parameters S secure For all j and k, if ij ≤ ok, then xj ≤ yk For all j and k, if oj ≤ ok, then yj ≤ yk Example transmatrix (a, b) lub{a, i} ≤ b a ≤ b

Compiler-Based Mechanisms Exceptions proc copy(x: int class { x }; var y: int class Low) var sum: int class { x }; z: int class Low; begin y := z := sum := 0; while z = 0 do begin sum := sum + x; y := y + 1; end When sum overflows, integer overflow trap Procedure exits Value of x is MAXINT/y Info flows from x to y, but x ≤ y never checked

Compiler-Based Mechanisms Exceptions (cont.) Need to handle exceptions explicitly on integer overflow, terminate loop on integer_overflow_exception sum do z := 1; Now info flows from sum to z, meaning sum ≤ z This is false (sum = { x } dominates z = Low)

Compiler-Based Mechanisms Infinite Loops proc copy(x: int 0..1 class { x }; var y: int 0..1 class Low) begin y := 0; while x = 0 do (* nothing *); y := 1; end If x = 0 initially, infinite loop If x = 1 initially, terminates with y set to 1 No explicit flows, but implicit flow from x to y This is an example of a covert channel

Compiler-Based Mechanisms Semaphores wait(x): if x = 0 then block until x > 0; x := x – 1; signal(x): x := x + 1; wait(sem); x := x + 1; Implicit flow from sem to x Semaphores in signal irrelevant Statement S is a wait shared(S): set of shared variables read information flows out of variables in shared(S) fglb(S): glb of assignment targets following S So, requirement is shared(S) ≤ fglb(S)

Compiler-Based Mechanisms Semaphores (cont.) begin S1; … Sn end All Si must be secure For all i, shared(Si) ≤ fglb(Si) Example begin x := y + z; (* S1 *) wait(sem); (* S2 *) a := b * c – x; (* S3 *) end lub{y, z} ≤ x lub{b, c, x} ≤ a shared(S2) ≤ fglb(S2) sem ≤ a

Compiler-Based Mechanisms Concurrent Loops Similar, but wait in loop affects all statements in loop while f(x1, ..., xn) do S; Let shared(Si) be the set of shared variables read, and let t1, ..., tm be the targets of assignments in the loop Iterative statement terminates S secure lub{x1, ..., xn} ≤ glb{t1, ..., tm} lub{shared(S1), ..., shared(Sn)} ≤ glb{t1, ..., tm}

Compiler-Based Mechanisms Concurrent Loops (cont.) Example while i < n do begin a[i] := item; wait(sem); i := i + 1; end; Loop terminates lub{i, n} ≤ glb{a[i], i} S1 secure if lub{i, item} ≤ a[i] S2 secure if sem ≤ i and sem ≤ a[i] S3 trivially secure

Execution-Based Mechanisms Detect and stop flows of information that violate policy Done at run time, not compile time Before the assignment y = f(x1, ..., xn) is executed, the execution-based mechanism verifies that lub(x1, ..., xn) ≤ y Problem: assume for security, x ≤ y if x = 1 then y := a; When x ≠ 1, x = High, y = Low, a = Low, appears okay but implicit flow violates condition

Execution-Based Mechanisms Fenton’s Data Mark Machine Each variable has an associated class Program counter (PC) has one too Idea: branches are assignments to PC, so you can treat implicit flows as explicit flows Stack-based machine, so everything done in terms of pushing onto and popping from a program stack skip means instruction not executed push(x, x) means push variable x and its security class x onto program stack pop(x, x) means pop top value and security class from program stack, assign them to variable x and its security class x respectively

Execution-Based Mechanisms Fenton’s Data Mark Machine (cont.) Instructions x := x + 1 (increment) Same as if PC ≤ x then x := x + 1; else skip Conditional instruction if x = 0 then goto n else x := x – 1 if x = 0 then {push(PC, PC); PC := lub{PC, x}; PC := n;} else {if PC ≤ x then x := x - 1 else skip;} branch and save PC on stack

Execution-Based Mechanisms Fenton’s Data Mark Machine (cont.) Return return same as pop(PC, PC); Branch instruction if’ x = 0 then goto n else x := x – 1 Same as if x = 0 then {if x ≤ PC then {PC := n} else skip} else {if PC ≤ x then {x := x - 1} else skip} branch without saving PC on stack Halt halt same as if program stack empty then halt Note stack empty to prevent user obtaining information from it after halting

Execution-Based Mechanisms Fenton’s Data Mark Machine (cont.) Example if x = 0 then goto 4 else x := x - 1 if z = 0 then goto 6 else z := z - 1 halt z := z - 1 return y := y - 1 x y z PC PC stack check 1 0 0 1 Low — 0 0 0 2 Low — Low ≤ x 0 0 0 6 z (3, Low) 0 1 0 7 z (3, Low) PC ≤ y 0 1 0 3 Low —

Execution-Based Mechanisms Variable Classes Up to now, classes fixed Check relationships on assignment, etc. Consider variable classes Fenton’s Data Mark Machine does this for PC On assignment of form y := f(x1, …, xn), y changed to lub{x1, …, xn} Need to consider implicit flows, also

Execution-Based Mechanisms Variable Classes (cont.) (* Copy value from x to y * Initially, x is 0 or 1 *) proc copy(x: int class { x }; var y: int class { y }) var z: int class variable { Low }; begin y := 0; z := 0; if x = 0 then z := 1; if z = 0 then y := 1; end; z changes when z assigned to Assume y < x

Execution-Based Mechanisms Variable Classes (cont.) x = 0 z := 0 sets z to Low if x = 0 then z := 1 sets z to 1 and z to x So on exit, y = 0 x = 1 if z = 0 then y := 1 sets y to 1 and checks that lub{Low, z} ≤ y So on exit, y = 1 Information flowed from x to y even though y < x

Execution-Based Mechanisms Variable Classes (cont.) Fenton’s Data Mark Machine detects implicit flows violating certification rules Raise class of variables assigned to in conditionals even when branch not taken Also, verify information flow requirements even when branch not taken Example In if x = 0 then z := 1, z raised to x whether or not x = 0 Certification check in next statement, that z ≤ y, fails, as z = x from previous statement, and y ≤ x

Execution-Based Mechanisms Variable Classes (cont.) Change classes only when explicit flows occur, but all flows (implicit as well as explicit) force certification checks Example When x = 0, first “if” sets z to Low then checks x ≤ z When x = 1, first “if” checks that x ≤ z This holds if and only if x = Low Not possible as y < x = Low and there is no such class