Information Flow Control

1. Information Flow Control Language and System Level

2. 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

3. 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

4. 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: ab N • Flow relation: iff information in class A is allowed to flow into class B Dorothy Denning

5. Example Security Classes (TS,[dip,mil]) top secret (TS,[dip]) secret (TS,[mil]) (S,[dip,mil]) confidential (TS,[]) (S,[mil]) (S,[dip]) public (S,[]} Adapted from K. Rosen Discrete Mathematics and its Applications, 2003.

6. Class Combining Operations (TS,[dip,mil]) least upper bound (TS,[dip]) (TS,[mil]) (S,[dip,mil]) (TS,[]) (S,[mil]) (S,[dip]) greatest lower bound (S,[]}

7. 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 ac • In the statement: if (a =0) {b = c;} • There is an explicit flow from c to b (bc) • There is an implicit flow from a to b (ba) • 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 (ab, ed) • implicit flows from c to a and from c to d (ac, dc)

8. Security Requirements • Elementary statement • S: b  a1,…,an • is secure if ba1 ,…,ban 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 ,…, Snwhere Si updates bi • is secure if bi c for i=1..n are secure • i.e. if is allowed

9. ⊕ Static Binding • Access Control • Process p can read from a only if ap • Process p can write to b only if pb • In general, • Data Mark Machine • Associate a security class with the program counter • For conditional structure c:S • Push p onto the stack • Set p to pc • Execute S • On exit restore p from stack • For statement S that with ba1,…,an • Verify that • ⊕

10. Static Binding • Compiler-based • For elementary statement S: f(a1,…,an)b • verify that is allowed • SetStob • For sequence S = S1;S2 • Set S to S1S2 • For conditional structure S = c: S1,…,Sm • Set S to S1 … Sm • Verify that c  S

11. 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

12. 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

13. 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=cifor some i and ldefault otherwise • Levels

14. Information Flow • General rule: • information can flow from O1to O2only if O2is at least as tainted as O1in every category • Information cannot flow from O1to O2 if O1is 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)

15. 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

16. 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

17. Kernel Object Types • Object structure • objectID (unique, 61 bit) • label (threads also have clearance label) • quota • metadata (64 bytes) • flags Segment: variable-length byte array

18. 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