Chapter 15: Information Flow Definitions Compiler-based mechanisms Execution-based mechanisms Examples Overview Basics and background Compiler-based

mechanisms Execution-based mechanisms Examples Security Pipeline Interface Secure Network Server Mail Guard

Example 2 Command is where: x, y equally likely to be either 0 or 1 if x = 1 then y := 0 else y := 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 Implicit Flow of Information Information flows from x to y without an explicit assignment of the form y := f(x) f(x) an arithmetic expression with variable x

Basics Bell-LaPadula Model embodies information flow policy Given compartments A, B, info can flow from A to B iff B dom A

Example from previous slide: if x = 1 then y := 0

else y := 1; So must look for implicit flows of information to analyze program Notation x means class of x In Bell-LaPadula based system, same as label of security compartment to which x belongs

Variables x, y assigned compartments x, y as well as values If x = A and y = B, and A dom B, then y := x allowed but not x := y

Information Flow Idea: info flows from x to y as a result of a sequence of commands c if you can deduce information about x before c from the value in y after c Example 1 Command is x := y + z; where: 0 y 7, equal probability z = 1 with prob. 1/2, z = 2 or 3 with prob. 1/4 each

x y means information can flow from an element in class of x to an element in class of y Or, information with a label placing it in class x can flow into class y

Compiler-Based Mechanisms Detect unauthorized information flows in a program during compilation Analysis not precise, but secure If a flow could violate policy (but may not), it is unauthorized

If you know final value of x, initial value of y can have at most 3 values, so information flows from y to x Page 1 of 9

No unauthorized path along which information could flow remains undetected

where ri is class of ith input or input/output argument Example

Set of statements certified with respect to information flow policy if flows in set of statements do not violate that policy 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 Information flowing out:

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 Note flows for both branches must be true unless compiler can determine that one branch will never be taken

:= a[i] Value of i, a[i] both affect result, so class is lub{ a[i], i } Information flowing in:

Declarations Notation:

x: int class { A, B } means x is an integer variable with security class at least lub{ A, B }, so lub{ A, B } x Distinguished classes Low, High Constants are always Low a[i] :=

Only value of a[i] affected, so class is a[i] Assignment Statements

x := y + z; Information flows from y, z to x, so this requires lub{ y, z } x

Input Parameters Parameters through which data passed into procedure Class of parameter is class of actual argument

More generally: y := f(x1, , xn) the relation lub{ x1, , xn } y must hold Compound Statements

ip: type class { ip } Output Parameters Parameters through which data passed out of procedure If data passed in, called input/output parameter

x := y + z; a := b * c x; First statement: lub{ y, z } x Second statement: lub{ b, c, x } a So, both must hold (i.e., be secure)

As information can flow from input parameters to output parameters, class must include this:

More generally: S1; Sn;

op: type class { r1, , rn }

Page 2 of 9

Each individual Si must be secure Conditional Statements

Hence no explicit flows

Need to detect implicit flows Basic block is sequence of statements that have one entry point and one exit point Control in block always flows from entry point to exit point

if x + y < z then a := b else d := b * c x; end The statement executed reveals information about x, y, z, so lub{ x, y, z } glb{ a, d }

More generally: if f(x1, , xn) then S1 else S2; end S1, S2 must be secure lub{ x1, , xn } glb{y | y target of assignment in S1, S2 } Iterative Statements

Example Program

proc tm(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 {i}; begin b1 i := 1; b2 L2: if i > 10 goto L7; b3 j := 1; b4 L4: if j > 10 then goto L6; b5 y[j][i] := x[i][j]; j := j + 1; goto L4;

while i < n do begin a[i] := b[i]; i := i + 1; end Same ideas as for if, but must terminate

More generally: while f(x1, , xn) do S; Loop must terminate; S must be secure lub{ x1, , xn } glb{y | y target of assignment in S } Iterative Statements

b6 L6: i := i + 1; goto L2; b7 L7: end; Flow of Control IFDs Idea: when two paths out of basic block, implicit flow occurs Because information says which path to take

while i < n do begin a[i] := b[i]; i := i + 1; end Same ideas as for if, but must terminate

More generally: while f(x1, , xn) do S; Loop must terminate; S must be secure lub{ x1, , xn } glb{y | y target of assignment in S } Goto Statements No assignments Page 3 of 9

When paths converge, either: Implicit flow becomes irrelevant; or Implicit flow becomes explicit

Immediate forward dominator of basic block b (written IFD(b)) is first basic block lying on all paths of execution passing through b IFD Example

In previous procedure: IFD(b1) = b2 one path

Example (continued) B4 = { b5 } Assignments to j, y[j][i]; conditional is j 10 Requires j glb{ j, y[j][i] } From declarations, means i y

IFD(b2) = b7 b2b7 or b2b3b6b2b7 IFD(b3) = b4 IFD(b4) = b6 IFD(b5) = b4 IFD(b6) = b2 one path b4b6 or b4b5b6 one path one path

Result:

Combine lub{ x, i } y; i y; i y Requirement is lub{ x, i } y

Requirements Bi is set of basic blocks along an execution path from bi to IFD(bi) Analogous to statements in conditional statement

Procedure Calls

tm(a, b); From previous slides, to be secure, lub{ x, i } y must hold In call, x corresponds to a, y to b Means that lub{ a, i } b, or a b

xi1, , xin variables in expression selecting which execution path containing basic blocks in Bi used Analogous to conditional expression

More generally: proc pn(i1, , im: int; var o1, , on: int) begin S end; S must be secure For all j and k, if ij ok, then xj yk For all j and k, if oj ok, then yj yk Exceptions

Requirements for secure: All statements in each basic blocks are secure lub{ xi1, , xin } glb{ y | y target of assignment in Bi }

Example of Requirements Within each basic block: proc copy(x: int class { x }; b3: Low j b6: lub{ Low, i } i var y: int class Low) var sum: int class { x }; Combining, lub{ x[i][j], i, j } y[j][i] } z: int class Low; From declarations, true when lub{ x, i } y begin y := z := sum := 0; Assignments to i, j, y[j][i]; conditional is i 10 Requires i glb{ i, j, y[j][i] } From declarations, true when i y Page 4 of 9 while z = 0 do begin sum := sum + x; y := y + 1;

b1: Low i

b5: lub{ x[i][j], i, j } y[j][i] }; lub{ Low, j } j

B2 = {b3, b4, b5, b6}

end end Exceptions (cont) When sum overflows, integer overflow trap Procedure exits Value of x is MAXINT/y Info flows from y to x, but x y never checked

Both executed atomically

Consider statement wait(sem); x := x + 1; Implicit flow from sem to x Certification must take this into account!

Flow Requirements Semaphores in signal irrelevant Dont affect information flow in that process

Need to handle exceptions explicitly Idea: on integer overflow, terminate loop

Statement S is a wait shared(S): set of shared variables read Idea: information flows out of variables in shared(S)

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)

Infinite Loops

fglb(S): glb of assignment targets following S So, requirement is shared(S) fglb(S)

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 Semaphores begin x := y + z;

begin S1; Sn end All Si must be secure For all i, shared(Si) fglb(Si)

Example

(* S1 *) (* S2 *)

wait(sem);

a := b * c x; (* S3 *) end Requirements: lub{ y, z } x lub{ b, c, x } a sem a Because fglb(S2) = a and shared(S2) = sem

Use these constructs: wait(x): if x = 0 then block until x > 0; x := x 1; signal(x): x := x + 1; x is semaphore, a shared variable Page 5 of 9

Concurrent Loops

Similar, but wait in loop affects all statements in loop Because if flow of control loops, statements in loop before wait may be executed after wait

So this is secure if lub{ y, z } x lub{ b, c, y}a

Soundness Above exposition intuitive Can be made rigorous: Express flows as types Equate certification to correct use of types Checking for valid information flows same as checking types conform to semantics imposed by security policy

Requirements Loop terminates All statements S1, , Sn in loop secure lub{ shared(S1), , shared(Sn) } glb(t1, , t m) Where t1, , tm are variables assigned to in loop

Execution-Based Mechanisms Detect and stop flows of information that violate policy Done at run time, not compile time

Loop Example

while i < n do begin a[i] := item; (* S1 *) wait(sem); i := i + 1; end Conditions for this to be secure: cobegin x := y + z; (* S1 *) No information flow among statements For S1, lub{ y, z } x For S2, lub{ b, c, y } a Loop terminates, so this condition met S1 secure if lub{ i, item } a[i] S2 secure if sem i and sem a[i] S3 trivially secure (* S2 *) (* S3 *)

Obvious approach: check explicit flows Problem: assume for security, x y

if x = 1 then y := a; When x 1, x = High, y = Low, a = Low, appears okaybut implicit flow violates condition!

Fentons 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 Instruction Description 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

cobegin/coend

a := b * c y; (* S2 *) coend

Security requirement is both must hold Page 6 of 9

Instructions x := x + 1 (increment) Same as:

1 2 3 4 5 6 7 x 1

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 return Initially x = 0 or x = 1, y = 0, z = 0 Program copies value of x to y Example Execution y 0 z 0 PC 1 2 PC Low Low stack check

if PC x then x := x + 1 else skip if x = 0 then goto n else x := x 1 (branch and save PC on stack) Same as:

if x = 0 then begin push(PC, PC); PC := lub{PC, x}; PC := n; end else if PC x then x := x - 1 else skip; More Instructions if x = 0 then goto n else x := x 1 (branch without saving PC on stack) Same as: 0 0 0

0 0 Low x 0 1 1 0 0 0

6 7 3

z z Low

(3, Low) (3, Low)PC y

if x = 0 then if x PC then PC := n else skip else if PC x then x := x - 1 else skip More Instructions return (go to just after last if) Same as:

Handling Errors Ignore statement that causes error, but continue execution If aborted or a visible exception taken, user could deduce information Means errors cannot be reported unless user has clearance at least equal to that of the information causing the error

pop(PC, PC); halt (stop) Same as:

Variable Classes Up to now, classes fixed Check relationships on assignment, etc.

if program stack empty then halt Note stack empty to prevent user obtaining information from it after halting

Consider variable classes Fentons Data Mark Machine does this for PC On assignment of form y := f(x1, , xn), y changed to lub{ x1, , xn }

Example Program Page 7 of 9

Need to consider implicit flows, also

Example Program

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

(* 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 Analysis of Example x=0 x=1 z := 0 sets z to Low if z = 0 then y := 1 sets y to 1 and checks that lub{Low, z} y So on exit, y = 1 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

Handling This (3) 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

Example Information Flow Control Systems Use access controls of various types to inhibit information flows Security Pipeline Interface Analyzes data moving from host to destination

Secure Network Server Mail Guard Controls flow of data between networks that have different security classifications

Information flowed from x to y even though y < x Handling This (1) Fentons Data Mark Machine detects implicit flows violating certification rules Handling This (2) Page 8 of 9 Use

Security Pipeline Interface SPI analyzes data going to, from host No access to host main memory Host has no control over SPI

Store files on first disk Store corresponding crypto checksums on second disk Host requests file from first disk SPI retrieves file, computes crypto checksum SPI retrieves files crypto checksum from second disk If a match, file is fine and forwarded to host If discrepency, file is compromised and host notified

Integrity information flow restricted here Corrupt file can be seen but will not be trusted

Secure Network Server Mail Guard (SNSMG) Filters analyze outgoing messages Check authorization of sender Sanitize message if needed (words and viruses, etc.)

Uses type checking to enforce this Incoming, outgoing messages of different type Only appropriate type can be moved in or out

Key Points Both amount of information, direction of flow important Flows can be explicit or implicit

Compiler-based checks flows at compile time Execution-based checks flows at run time

Page 9 of 9