Information Flow

Language and System Level

1Dennis Kafura – CS5204 – Operating Systems

Information Flow

Concept

Information flow Long-term confinement of information to authorized

receivers Controls how information moves among data handlers

and data storage units Applied at language, system, or application levels

Examples: Insure that “secret” data is only revealed to individuals

with a suitably high clearance level Guarantee that information available to a process

cannot leak to the network Certify that the outputs of a program only contain

information derived from specified inputs

Dennis Kafura – CS5204 – Operating Systems 2

Information Flow

System Example

Guarantee that the anti-virus (AV) scanner cannot leak to the network any data found in its scan of user files

Possible leak methods Send data directly to a network connection Conspire with other processes (e.g, sendmail or httpd) Subvert another process and use its network access to send data Leave data in /tmp for other processes (e.g., the AV update daemon) to

send Use other in/direct means of communication with the update daemon

Dennis Kafura – CS5204 – Operating Systems 3

Information Flow

Denning Model

Flow model where N = {a,b,…} is a set of logical storage objects P = {p,q,…} is a set of processes (active objects) SC = {A.,B,…} is a set of security classes

Disjoint classes of information Each is bound to a security class

Notation: a may be static or dynamic (varies with content)

Class combining operator: a b N Flow relation: iff information in class A is allowed to

flow into class B

Dennis Kafura – CS5204 – Operating Systems 4

Information Flow

Example Security Classes

Dennis Kafura – CS5204 – Operating Systems 5

public

top secret

confidential

secret (TS,[dip])

(S,[]}

(TS,[]) (S,[mil]) (S,[dip])

(TS,[mil]) (S,[dip,mil])

(TS,[dip,mil])

Adapted from K. Rosen Discrete Mathematics and its Applications, 2003.

Information Flow

Class Combining Operations

Dennis Kafura – CS5204 – Operating Systems 6

(TS,[dip])

(S,[]}

(TS,[])(S,[mil]) (S,[dip])

(TS,[mil]) (S,[dip,mil])

(TS,[dip,mil])

least upper bound

greatest lower bound

Information Flow

Implicit/Explicit flows

In the statement: a=b+c; There is explicit flow from b to a and from c to a Here written as a b and ac

In the statement: if (a =0) {b = c;} There is an explicit flow from c to b (bc) There is an implicit flow from a to b (ba)

Because testing the value of b before and after the statement can reveal the value of a

In the statement: if (c) {a=b+1;d=e+2;} explicit flows from b to a and from e to d (ab, ed) implicit flows from c to a and from c to d (ac, dc)

Dennis Kafura – CS5204 – Operating Systems 7

Information Flow

Security Requirements

Elementary statement S: b a1,…,an is secure if ba1 ,…, ban are secure i.e., if a1 b ,…, an b i.e., if is allowed

Sequence S = S1; S2

Is secure if both S1 and S2 are secure

Conditional S = c: S1 ,…, Sn where Si updates bi is secure if bi c for i=1..n are secure i.e. if is allowed

Dennis Kafura – CS5204 – Operating Systems 8

Information Flow

Static Binding

Access Control Process p can read from a only if ap Process p can write to b only if pb In general,

Data Mark Machine Associate a security class with the program counter For conditional statement c:S

Push p onto the stack Set p to p c

For statement S that with ba1,…,an Verify that

Dennis Kafura – CS5204 – Operating Systems 9

⊕

⊕

Information Flow

Static Binding

Compiler-based For elementary statement S: f(a1,…,an)b

verify that is allowed Set S to b

For sequence S = S1;S2

Set S to S1 S2

For conditional structure S = c: S1,…,Sm

Set S to S1 … Sm

Verify that c S

Dennis Kafura – CS5204 – Operating Systems 10

Information Flow

Dynamic Binding

A pure dynamic binding is not practical Typical that some objects and most users have a static

security class

Dynamic Data Mark Machine Difficult to account for implicit flows, so… Compiler determines implicit flows and Inserts additional instructions to update class associated

with program counter accordingly Accounts for implicit flows even if flow not executed

Dennis Kafura – CS5204 – Operating Systems 11

Information Flow

HiStar : System Level Flow Control

Basic ideas Files and process are associated with a label whose taint

restricts the flow to lesser tainted components Many categories of taint each owned by its creator Selected components (e.g., wrap) can be given

untainting privileges

Dennis Kafura – CS5204 – Operating Systems 12

Information Flow

Labels

Structure L = {c1l1, c2l2,…,cnln,ldefault}

Each ci is a category and li is the taint level in that category

ldefault is the default level for unnamed categories L(c) = li if c=ci for some i and ldefault otherwise

Levels

Dennis Kafura – CS5204 – Operating Systems 13

Information Flow

Information Flow

General rule: information can flow from O1 to O2 only if O2 is at least as

tainted as O1 in every category Information cannot flow from O1 to O2 if O1 is more

tainted in some category than O2

Example Thread T with LT={1}, object O with LO={c3,1} LT(c)=1 < 3=LO(c) Flow is permitted from T to O (i.e., T can write to O) No flow permitted from O to T (i.e., T cannot

read/observe O)

Dennis Kafura – CS5204 – Operating Systems 14

Information Flow

Example with Labels

User data labels set so that only owner can read (br3) and write (bw0)

Wrap program has ownership to read (br⋆) user data which it delegates to scanner

Wrap creates category v to (1) prevent the scanner from modifying User Data (since User Data has default level 1) and (2) prevent scanner from communicating with network

Dennis Kafura – CS5204 – Operating Systems 15

Information Flow

Notation

Information flow Treatment of level ⋆

⋆ should be high for reading, but low for writing Notation provides two ownership symbols

Used as L⋆ and L⍟; for example if L={a , ⋆ b⍟, 1} then L⍟ = {a⍟,b⍟,1} and L⋆ = {a⋆,b⋆,1}

Flow restriction: T can read/observe O only if T can write/modify O only if

Dennis Kafura – CS5204 – Operating Systems 16

Information Flow

Kernel Object Types

Object structure objectID (unique, 61 bit) label (threads also have clearance label) quota metadata (64 bytes) flags

Dennis Kafura – CS5204 – Operating Systems 17

Segment: variable-lengthbyte array

Information Flow

Design Rationale

Kernel interface The contents of object A can only affect object B if, for

every category c in which A is more tainted than B, a thread owning c takes part in the process.

Provides end-to-end guarantee of which system components can affect which others without need to understand component details

Application structure Organize applications so that key categories are owned

by small amounts of code Bulk of the system is not security critical

Dennis Kafura – CS5204 – Operating Systems 18

Information Flow

Threads

Labels normal label, LT

clearance label, CT , giving an upper bound on its own label and the label of objects it creates or grants storage to

Category creation Creates a random previously unused category with LT(c) ⋆ and CT(c) 3

Raise its own label to L provided Change clearance label to C provided Object with label L created by T have Spawned threads T’ have labels T can read label of T’ only if Have a one-page local segment for scratch space

Dennis Kafura – CS5204 – Operating Systems 19

Information Flow

Containers

Hierarchical object allocation/deallocation Creating object with label L in container D by thread

T requires and object in a container is referenced by a

<container ID, object ID> container entry Automatic deallocation of objects unreachable from a

specially-designated root container Quotas

Limits each objects storage usage Container usage is its own space + quotas of all

contained objects

Dennis Kafura – CS5204 – Operating Systems 20

Information Flow

Address Spaces

Associated with a running thread A collection of segments mapped via the list

VA <S, offset, npages, flags> S = <D,O> offset, napges can specify subset of S flags contain memory permission bits

Thread T can modify address space A only if use or observe A only if

Dennis Kafura – CS5204 – Operating Systems 21

Information Flow

Gates

Provide protected control transfer Arguments and return values passed via thread local segment May be used to transfer privileges

Dennis Kafura – CS5204 – Operating Systems 22

[stack pointer]

Gate

LG, CGState

address space

entry pointT

closure arguments

Information Flow

Invocation using Gates

Invocation permitted when

Note: LV used only for verification at Gate

Dennis Kafura – CS5204 – Operating Systems 23

[stack pointer]

Gate

LG, CGState

address space

entry pointT

closure arguments

(LR, CR)

LV

Information Flow

HiStar Implementation

Design for a simple interface to a small fully-trusted kernel Typical Unix abstractions provided at the user level

Dennis Kafura – CS5204 – Operating Systems 24

15,200 lines

10,000 lines

HiStar Kernel

Linux sys call emulation

uClibcne

twor

kda

emon

auth

entic

atio

nda

emon

Information Flow

Processes in HiStar

Dennis Kafura – CS5204 – Operating Systems 25

Note: a process is a user-level convention

Information Flow

User Authentication

No highly-trusted processes User supplied (tailorable) authentication service Directory Service: maps user names to authentication

service daemons (returns gate to user auth. service) Authentication service: owns categories and grants them

to successful login clients

Complication: login does not trust the authenticationservice with the user’s password!

Dennis Kafura – CS5204 – Operating Systems 26

Information Flow

User Authentication

Dennis Kafura – CS5204 – Operating Systems 27

Solution: a three step process Key point: login and UAS collaborate

to create trusted check gate Login creates check code in

segment marked immutable and a gate with clearance to have password

UAS can verify code to assure safe execution with user privileges

Information Flow

Performance: microbenchmarks

Dennis Kafura – CS5204 – Operating Systems 28

Information Flow

Performance: application-level

Dennis Kafura – CS5204 – Operating Systems 29