Secure Provenance Policies in SELinks

1. Secure Provenance Policies in SELinks Michael Hicks with Nikhil Swamy and Brian Corcoran University of Maryland, College Park, USA

2. or … Fable (and SELinks):Enforcing User-defined Security Policies (including provenance) for Web Apps Michael Hicks with Nikhil Swamy and Brian Corcoran University of Maryland, College Park, USA

3. Goal: Reliable Enforcement of Security Policies • Software systems aim to enforce a variety of security policies • Flavors of access control (RBAC, HBAC, …) • Security automata, stack inspection • Information flow, tainting, provenance, … • But policies are regularly circumvented due to software errors • Access control bypasses, information leaks, missing input validation checks, etc.

4. Security-typed Programming LanguagesShape of a solution • Idea: Express the policy in the programming language’s types • E.g., annotate a type with a security level from an MLS security policy: int{secret} vs. int{public} • If the program type checks, it properly enforces the security policy • E.g., language designer proves that type checking implies a property like noninterference, which states that secret data cannot be learned via public channels

5. One size does not fit all • Existing security-typed languages focus on specific sorts of policies • Jif, FlowCaml enforce information flow policies • But what about flavors of access control, stack inspection, security automata, … ? • Provenance tracking is a security concern: must be trusted as correct for meaningful audit • Want the benefits of security typing but the flexibility to define a variety of policies

6. Our approach: FableA type system for user-defined security policies • Types of sensitive data associated with security labels • The semantics of labels is programmer-defined • Given the semantics of labels, and the Fable metatheory, the policy designer can prove that type-correct programs enjoy relevant security properties • I.e., the policy is being enforced correctly

7. Type correct? SECURE The Fable approach, pictorially Security Proof 2. Prove that this library correctly enforces security policy for type-correct programs 3. Write program that uses this policy - if it typechecks then it is secure 1. Design format and semantics for labels as a library Access Control Library Application Program Application Program 2 Application Program 3 Reuse library for several applications …

8. Develop new libraries for new policies Security Proof Access Control Library Information Flow Library Data Provenance Library Information Release Pol. Library Security Automata Library Type correct? SECURE Application Program

9. Applications may use several policies Security Proof Security Proof Access Control Library Data Provenance Library Application Program

10. The rest of the talk • An overview of Fable using access control and provenance tracking as examples • SELinks: Implementation of Fable as an extension to the Links web programming language • SEWiki: A wiki that enforces fine-grained access control and provenance policies, built with SELinks • Also built a model health record database, SESpine, and a secured on-line store, SEWinestore

11. Customizable Security LabelsAssociate Data and Policy • Labels can be arbitrary data values • labl = High • labm = ACL(nswamy,bjc,mwh) • Protected data refers to its label in its type • int x = … // unprotected data • int{l}y = … // protected by labell • bool{Low}z = … // protected by labelLow • In general, protected data has a dependent type t{e} • t is the type of the underlying data • e is an expression that represents a security label

12. High integrity user credential. Produced, say, by a login function Data protected by acl Check if cred is mentioned in the ACL  String Success: unlabel data and expose to application code Only policy code can destruct a labeled value Semantics of Security LabelsAn Access Control Enforcement Policy a list, e.g.,[uid1; uid2; …] sig access : (Cred{High}, acl<-Acl, funaccess (cred, acl, data) policy { ifmember (cred, acl) then unlabel (data) else error(“access denied”) } • {acl}) -> • String{acl}) ->String policy keyword identifies this code as privileged

13. Credential of user currently logged in “Phantom” label polymorphism • var (acl2:Acl,f2:File{acl2})= open_in “f2.txt” ; Open file: get acl and file handle And must be the right check • printstr (access(user,acl2,line)) ; Infer instantiation of label variable Must call policy authorization check before printing String{acl2} -> String String{acl} Access Control in Action • access: (UserCred{High},x<-Acl,String{x})-> String • readline: phantoml. File{l} -> String{l} • printstr: String -> unit var user:UserCred{High} = login … ; var (acl:Acl,fh:File{acl})= open_in “f.txt” ; • var line:String{acl} = readline fh ; • printstr (access (user,acl,line)) ; • printstr line ;

14. Other policies • Information flow policies with static and dynamic labels • Proved that both ensure noninterference • Provenance policy for dynamically tracking data dependencies • Proved that all relevant dependencies are tracked (completeness) • Stateful, automata-based policies for information release • Proved that release obligations satisfied prior to information release (see PLAS 2008 paper)

15. Provenance Tracking in Fable Values tagged with labels to reflect their origin or derivation • E.g., track all dependences through a computation • Correct attribution • Accurately associate provenance with data • Complete mediation • Every sensitive operation on tracked data propagates provenance correctly • Metadata security • Can protect the confidentiality and integrity of the provenance itself

16. Representation of provenance tracked data Computation depends on both x and y Tag with provenance of both x and y Data Provenance Tracking A dependently typed pair containing the provenance metadata l and the data  Objective: track dependences in the label associated with the result of a computation • typename Prov() = (l<-ProvLab,{l}) • var x:Prov int = (Alice, label(0,Alice)) ; • var y:Prov int = (Bob, label(1,Bob)) ; • var l = Union(Alice,Bob) ; (l, label(x+y, l))

17. Policy tracks provenance through function application A function tagged with provenance Argument tagged with provenance Unlabel before applying f to x Split each pair Return type: Prov  Provenance of result, includes provenance of f and x Data Provenance Tracking • typename Prov=(l<-ProvLab,{l}) • sig apply (Prov ( -> ), Prov ) -> Prov  • fun apply (lf,mx) policy { • var (l, f)= lf ; • var (m, x)= mx ; • var result = unlabel(f)(unlabel(x)) ; • var l_result = Union(l, m) ; • (l_result, label(result, l_result)) • }

18. Protect the provenance label with its own security policy Provenance data can itself be confidential Protecting Provenance Information • typename Prov = (l<-ProvLab{Acl(Admins)},{unlabel l}) • typename Prov = (l<-ProvLab,{l}) • var l = File “secret.txt” ; • (label(l, Acl(Admins)), label(“secret data”, l)) • var l = File “secret.txt” ; • (l, label(“secret data”, l))

19. Implemented Fable as part of the Links web programming language • We call it “security-enhanced” Links

20. Table name Custom datatype extensions allow SELinks values to be stored in DB (implemented for Postgres and Oracle) 1st column is the primary key 2nd column is a label that protects the data in the 3rd column A DB Schema in SELinks • Every DB table is given an SELinks type • Types can include label dependences table “labeled_doc” with = (id : Int, acl: Acl, data : String{acl}) from database ”db”

21. For each row in the table Where-clause checks access control policy, compiled to stored DB proc, to inspect data Result is a list of all rows that satisfy the where-clause Accessing Labeled DB Data • Links treats every table as a list of tuples • Queries are list comprehensions • Search for all rows that contain the string “foo” var ld =table … with … from db; var result = for (row <-- ld) where(access (cred, row.label, row.data)~ /foo/) [row];

22. Application Experience: SEWiki • SEWiki: A blog/wiki written in SELinks • Supports standard features for page creation, hyperlinking, formatting, etc. • Enforces a fine-grained composite policy on document elements • Access control governs read/writes (200 LOC) • Provenance of changes made (100 LOC) • Roughly 3000 lines of SELinks code • SESpine: Health record web app/DB • SEWinestore: E-commerce app from Links

23. A document with components at different security levels Record provenance: revision history etc. Filter out part of document not accessible to this user saves changes Edits content in visible part of document Overview of SEWiki server client

26. Documents are n-ary trees with with words at the leaves A dependently typed pair Some subtrees can be protected by a security label First component a label l that protects the subtree in the second component Fine-grained Labeling of Documents typenameBlock = mu block. ([| Word: String | Compound: [block] | Labeled: (l<-Label, block{l}) | … |]);

27. Provenance used to track document modifications Labels may have an access control and a provenance component Label Format typenameLabel = mu label. [| Composite: [label] | Acl: (read:[Group], write:[Group]) | Prov: [ProvAction] |]; typenameProvAction = ( oper: ProvOp, user: Group, … ); typenameProvOp = [| Create | Modify | Relabel | Copy | Delete | Restore |];

29. Assessment • Relatively easy to work with simple policies • Easy to write policy code and to interpose policy checks • Policy code can be packaged as reusable components • Shared access control code between SEWiki, SEWinestore, and SESpine. • Shared provenance code with SEWiki and SESpine • More complex policies (information flow) are harder • Wrap all operations in policy functions to track implicit flows • Similar problem with finer-grained provenance tracking • Automata policies require writing in a store-passing style

30. Ongoing Work • Automatic insertion of calls to policy functions • View the problem as “type coercion insertion” • Paper upcoming, ICFP ‘09 (in Edinburgh!) • Better support for policy composition • If policy/label p yields property P, and policy/label q yields property Q, then labels (p,q) yield property P and Q. And: unrelated policies do not interfere. • Mechanized metatheory for Fable policies • Semi-automated proofs of high-level security properties

31. Conclusions • Enforcement of user-defined security policies brings the benefit of security typing to a wide range of policies • Notably, we can prove that provenance is tracked correctly • Security assurances as strong as those provided by special-purpose systems • Fable metatheory assists in security proof • Works for web apps! • Download SELinks, try our demos http://www.cs.umd.edu/projects/PL/selinks

32. EXTRA SLIDES

33. And the user Alice is not authorized to access x member Alice acl -->* false Non-ObservabilityCorrectness of Access Control • Given an application e with x protected by some aclu:UserCred{High}, x:bool{acl}|- e :t • Then, executions with x=true and x=false are identical • e[x -> true, u -> Alice] --> e’ [x -> true, u -> Alice ] • <=> • e[x -> false, u -> Alice] --> e’ [x -> false, u -> Alice ]

34. SQL compiled from list comprehension Stored proc. compiled from enforcement policy Executing SELinks Queries in the DB • Policy functions in a query must be executed in DB • Essential for reasonable performance • Solution: compile SELinks enforcement policies to DB stored procedures • SQL queries can call these procedures to enforce a policy SELECT pageid FROM (SELECT tab.label AS label, tab.pageid AS pageid, tab.text AS text, access(’mwh', tab.label, tab.text) AS tmp1 FROM page_blocks AS tab) AS tab WHERE (CASE … END) CREATE FUNCTION access(text, record, anyelement) RETURNS variant AS $$ DECLARE … BEGIN … END; $$ language ‘plpgsql’

35. lub just a user-defined function Concat’d string at least as confidential as the arguments • letlub _ High = High • lub High _ = High • lub _ _ = Low Type checker can reduce these expressions to show type equivalence Information Flow in Fable • Static enforcement via type conversions • strcat: phantom l,m. String{l} -> String{m} -> String{lub l m} • String{lub Low High} ~ String{High}

36. send requires messages to be sent on sockets at the same security level • send sock (strcat line1 line2) • send sock (strcat line1 line2) String{lub Low Low} ~ String{Low} String{lub Low High} ~ String{High} Information Flow in Fable • strcat: phantom l,m. String{l} -> String{m} -> String{lub l m} • Static enforcement via type conversions • send: phantom l. Socket{l} -> String{l} -> unit • letsock:Socket{Low} = … in • letline1:String{Low} = … in • letline2:String{Low} = … in • letline1:String{Low} = … in • letline2:String{High} = … in

37. match label with Low->send socket line • | High -> () line protected by label which is unknown statically Refine the type of line to String{Low} based on runtime check Information Flow in Fable • Dynamic enforcement via type refinements • send: phantom l. Socket{l} -> String{l} -> unit • letsock:Socket{Low} = … in • let label, line:String{label} = … in

38. Label Modification

39. Label Modification • Changing access control labels must be done through relabelBlock policy • Modifies labels • Also adds Relabel provenance label • Ensures all relabeling actions are logged • Records complete security history

40. Copy/Paste • Based on Copy/Paste DB from “Provenance Management in Curated Databases” • Allows derivative pages to have increased/decreased levels of access control • “Read-only” users could modify personal version • Block could be copied into classified report • (no access for original authors)

41. Example: Modify Block Policy • Modifies the content of a block • Usually in context of editing text • Requires successful access control check • Records action as provenance label

42. Modify Block Policy

43. Modify Block Code • fun modifyBlock(cred,page,path,block){ • fun replace (li, _) { • var lProv =mkProvLabel(Modify,cred); • var l=joinLabels(li,lProv); • labelBlock(l,block) • } • applyWriteToBlock(cred,replace,path,page) • }

44. Apply Write Policy • fun applyWriteToBlock(cred, f, path, page) • policy { • var (l, oldBlk) = getBlock(cred, page, path); • var newBlk = applyWrite(cred, f, l, oldBlk); • dbreplaceBlock(cred, oldBlk, newBlk) • }

45. Apply Write Policy • sig applyWriteToBlock : • (Cred, (Doc)->Doc, Path, Page{l}) -> Page{l} • fun applyWriteToBlock(cred, f, path, page) • policy { • var (l, oldBlk) = getBlock(cred, page, path); • var newBlk = applyWrite(cred, f, l, oldBlk); • dbreplaceBlock(cred, oldBlk, newBlk) • }