Information Flow

1. Information Flow Language and System Level Dennis Kafura – CS5204 – Operating Systems

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 Dennis Kafura – CS5204 – Operating Systems

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 Dennis Kafura – CS5204 – Operating Systems

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 Dennis Kafura – CS5204 – Operating Systems

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

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,[]} Dennis Kafura – CS5204 – Operating Systems

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) Dennis Kafura – CS5204 – Operating Systems

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 Dennis Kafura – CS5204 – Operating Systems

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 statement c:S • Push p onto the stack • Set p to pc • For statement S that with ba1,…,an • Verify that Dennis Kafura – CS5204 – Operating Systems

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 Dennis Kafura – CS5204 – Operating Systems

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 Dennis Kafura – CS5204 – Operating Systems

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 Dennis Kafura – CS5204 – Operating Systems

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 Dennis Kafura – CS5204 – Operating Systems

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) Dennis Kafura – CS5204 – Operating Systems

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 Dennis Kafura – CS5204 – Operating Systems

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 Dennis Kafura – CS5204 – Operating Systems

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

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 Dennis Kafura – CS5204 – Operating Systems

19. Threads • Labels • normal label, LT • clearancelabel, 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

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

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

22. Gates [stack pointer] LG, CG State address space closure arguments Gate T entry point Provide protected control transfer Arguments and return values passed via thread local segment May be used to transfer privileges Dennis Kafura – CS5204 – Operating Systems

23. Invocation using Gates [stack pointer] LG, CG State address space closure arguments Gate (LR, CR) T entry point LV Invocation permitted when Note: LV used only for verification at Gate Dennis Kafura – CS5204 – Operating Systems

24. HiStar Implementation uClibc authentication daemon network daemon Linux sys call emulation 10,000 lines HiStar Kernel 15,200 lines Design for a simple interface to a small fully-trusted kernel Typical Unix abstractions provided at the user level Dennis Kafura – CS5204 – Operating Systems

25. Processes in HiStar • Note: a process is a user-level convention Dennis Kafura – CS5204 – Operating Systems

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

27. User Authentication Dennis Kafura – CS5204 – Operating Systems • 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

28. Performance: microbenchmarks Dennis Kafura – CS5204 – Operating Systems

29. Performance: application-level Dennis Kafura – CS5204 – Operating Systems