fall, 2011 - privacy&security - virginia tech – computer science click to edit master title...

Fall, 2011 - Privacy&Security - Virginia Tech – Computer Science

Click to edit Master title style

Decentralized Information Flow

A paper by Myers/Liskov



2Fall, 2011 - Privacy&Security - Virginia Tech – Computer Science

Motivation &Goals Example Model

Labels• Confidentiality (reading)• Integrity (writing) [presented later]

Principal hierarchy Relabeling Declassification

Jif (Java Information Flow) Static and dynamic checking

Overview




End-end confidentiality Need to control propagation/release of information beyond access control

guarantees Need for more precise and practical model

Model Decentralized label model

• Independent principals, not a central authority Copes with

• Untrusted code• Mutual suspicion

Protection for users/group (not just organization) Richer notion of declassification

• Need in practical systems to avoid “label creep”• Does not need trusted subject (each principal declassifies their own data)

Finer grain of protection via JIF

Motivation & Goals




Bob and Tax preparer must cooperate Each have sensitive information to

protect from the other Bob cannot inspect Tax preparer code Both must trust execution platform

Example




A process can act on behalf of a (set of) principal(s) p acts for q p has all the powers of q Written

Represents Individuals Group/role

Model: Principals




Confidentiality labels (integrity later) Form

{ policy1, policy2, …, policyn} Policy is owner : list of readers Example L = {o1: r1 , r2 ; , o2: r2 , r3 } All policies in a label must be satisfied In example, r2 can read an object labeled by L

Model: Labels




Intuition - Confidentiality

confidentiality restrictive

high

low less

more

assignmentdestination

source

declassification

after

before

: union of all policies (each of which must be met), intersection of all readers by a given principal

: intersection of all policies, union of all readers by a given principal

lattice




Assignment (value/L1 variable/L2 ) iff it is safe Safety

L2 is at least as restrictive as L1

every policy in L1 will be enforced by L2

Notation Label restriction Policy “covers”

• J’s owner can act for I’s owner (or is the same owner)• J’s readers are a subset of I’s readers (or are the same)

Incremental relabeling rules Remove a reader Add a policy Add a reader r’ if r is in policy and Replace an owner o with o’ if

Relabeling




Relabeling Examples




For policy I Owner: o(I) Explicit readers: r(I) Implicit readers:

Rule

Complete relabeling rule




Combining Information




Goal: deliberate action by process to weaken/relax confidentiality

Authority – the set of principals on whose behalf a process is allowed to act

Performed on a per-owner basis No centralized declassifier needed Owners cannot affect each others policies

Rule

Declassification – Confidentiality Labels




requires WebTax to declassify final tax form to be readable by Bob.

Declassification: example




Form { policy1, policy2 ,…, policyn} Policy is owner : list of writers Example L = {o1: w1 , w2 ; , o2: w2 , w3 }

Interpretation (of a policy) A guarantee by the policy owner that the data can only be affected by

the list of writers The fewer writers, the less restrictive and the stronger the integrity

guaranteeThe most restrictive label is {}

• States no guarantee of source(s)/contamination• All users may have written to the data• Can only be used only when receiver imposes no integrity requirements

Model: Integrity Labels




Intuition - Integrity

integrity

low

high

guarantee

strong

weak

assignment

destination

source

declassification

after

before

lattice

: intersection of all policies , union of all writers by a given principal

: union of all policies, intersection of all readers by a given principal

restrictive

less

more




Assignment (value/L1 variable/L2 ) iff it is safe Safety: L2 is more restrictive than L1 (no less restrictive?) Notation: Examples:

{o : w1} {o: w1, w2} is allowed { o : w1, w3} {o: w1, w2} is not allowed { o : w1; o’: w3} {o: w1, w2} is allowed

Incremental relabeling rules Add a writer Remove a policy Replace writer w’ by a writer w where Add a policy J that is identical to policy I except that

Relabeling Integrity Labels




Goal: deliberate act by a process to weaken/relax integrity guarantees

Authority: the set of principles on whose behalf a process is allowed to act

Performed on a per-owner basis No centralized declassifier needed Owners cannot affect each others policies

Rule L1 can be declassified to L2 if is an integrity label with a policy {p: all } for every principal

p in the authority of the process; all is a list of all users

Declassification – Integrity Labels




Extends Java with information flow checking New features

Static checking of code privileges and also dynamic granting/checking of authority

Label polymorphism Run-time checking when needed; run-time checks

are checked to guard against leaks Automatic label inference reduces need for manual

labeling Implicit flows accounted for by associating a static

program-counter label (pc) with every statement

Jif – Java Information Flow




Labeled type associate a type, t, with an information flow label, l, as t{l} Label checking insures that the apparent label of a value

is at least as restrictive as the actual label of every value that might affect it.

Additional features Declassify operator An actsFor statement Procedure calls my delegate a portion of the authority of

the caller Type “label” permits run-time label checking

Overview




Example

fall, 2011 - privacy&security - virginia tech – computer science click to edit master title...

Documents