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

1

Secure Provenance Policies in SELinks

Michael Hickswith Nikhil Swamy and Brian CorcoranUniversity of Maryland, College Park, USA

2

Fable (and SELinks): Enforcing User-defined Security Policies

(including provenance) for Web Apps

Michael Hickswith Nikhil Swamy and Brian CorcoranUniversity of Maryland, College Park, USA

or …

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

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

The Fable approach, pictorially

Access Control Library

SecurityProof

Application Program

Type correct?

SECURE

1. Design format and semantics for labels as a library

Application Program 2Application Program 3

Reuse library for several applications …

8

Develop new libraries for new policies

AccessControlLibrary

Application Program

Type correct?

SECURE

Information Flow

Library

DataProvenance

Library

InformationRelease Pol.

Library

SecurityAutomata

Library

SecurityProof

9

Applications may use several policies

Access Control Library

SecurityProof

Application Program

DataProvenance

Library

SecurityProof

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– lab l = High– lab m = ACL(nswamy,bjc,mwh)

• Protected data refers to its label in its type– int x = … // unprotected data– int{l} y = … // protected by label l– bool{Low} z = … // protected by label Low

• 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

Semantics of Security LabelsAn Access Control Enforcement Policy

sig access : (Cred{High}, acl<-Acl, fun access (cred, acl, data) policy { if member (cred, acl) then

unlabel (data) else error(“access denied”)}

Success: unlabel data and expose to application codeOnly policy code can destruct a labeled value

a list, e.g., [uid1; uid2; …]High integrity user credential.Produced, say, by a login function

Check if cred is mentioned in the ACL

String

Data protected by acl

{acl}) -> String{acl}) -> String

policy keyword identifiesthis code as privileged

13

Access Control in Action

var user:UserCred{High} = login … ; var (acl:Acl, fh:File{acl}) = open_in “f.txt” ;

readline: phantom l. File{l} -> String{l}

var line:String{acl} = readline fh ;

printstr: String -> unit

printstr line ;

printstr (access (user,acl,line)) ;

Credential of user currently logged in

printstr (access(user,acl2,line)) ;

var (acl2:Acl, f2:File{acl2}) = open_in “f2.txt” ;

Open file: get acl and file handle

“Phantom” label polymorphism

Infer instantiation of label variableMust call policy authorization check before printing

access: (UserCred{High},x<-Acl,String{x}) -> String

String{acl2} -> String

String{acl}

And must be the right check

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

1. Correct attribution• Accurately associate provenance with data

2. Complete mediation• Every sensitive operation on tracked data propagates provenance correctly

3. Metadata security• Can protect the confidentiality and integrity of the provenance itself

16

Data Provenance Tracking

Objective: track dependences in the label associated with the result of a computation

Representation of provenance tracked data

A dependently typed pair containing the provenance metadata l and the data

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))

Computation depends on both x and y

Tag with provenance of both x and y

17

Data Provenance Tracking

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))}

typename Prov = (l<-ProvLab,{l})Policy tracks provenance through function application

A function tagged with provenance

Argument tagged with provenance

Split each pair

Unlabel before applying f to x

Provenance of result, includes provenance of f and x

Return type: Prov

18

Protecting Provenance Information

var l = File “secret.txt” ;(label(l, Acl(Admins)), label(“secret data”, l))var l = File “secret.txt” ;(l, label(“secret data”, l))

Provenance data can itself be confidential

Protect the provenance label with its own security policy

typename Prov = (l<-ProvLab{Acl(Admins)},{unlabel l})typename Prov = (l<-ProvLab,{l})

19

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

20

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”

Table name

1st column is the primary key2nd column is a label that protects thedata in the 3rd column

Custom datatype extensionsallow SELinks values to be stored in DB (implemented for Postgres and Oracle)

21

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];

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

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

Overview of SEWiki

23

Edits content in visiblepart of document

A document withcomponents at different security levels

server

client

saves changes

Filter out part of documentnot accessible to this user

Record provenance:revision history etc.

24

25

26

Fine-grained Labeling of Documents

typename Block = mu block. ([| Word: String | Compound: [block] | Labeled: (l<-Label, block{l}) | … |]);

Documents are n-ary treeswith with words at the leaves

Some subtrees can be protectedby a security label

A dependently typed pair

First component a label l that protectsthe subtree in the second component

27

Label Format

typename Label = mu label. [| Composite: [label] | Acl: (read:[Group], write:[Group]) | Prov: [ProvAction] |];

typename ProvAction = ( oper: ProvOp, user: Group, … );

typename ProvOp = [| Create | Modify | Relabel | Copy | Delete | Restore |];

Labels may have an access controland a provenance component

Provenance used to track document modifications

28

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

http://www.cs.umd.edu/projects/PL/selinks

• 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

32

EXTRA SLIDES

33

Non-ObservabilityCorrectness of Access Control

• Given an application e with x protected by some acl u:UserCred{High}, x:bool{acl} |- e : t

member Alice acl -->* false

• And the user Alice is not authorized to access x

• 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

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’

SQL compiled from list comprehension

Stored proc. compiledfrom enforcement policy

35

Information Flow in Fable• Static enforcement via type conversions

strcat: phantom l,m. String{l} -> String{m} -> String{lub l m}

Concat’d string at least as confidentialas the arguments

Type checker can reduce these expressions to show type equivalence

String{lub Low High} ~ String{High}

let lub _ High = High

lub High _ = High lub _ _ = Low

lub just a user-defined function

36

Information Flow in Fable• Static enforcement via type conversions

strcat: phantom l,m. String{l} -> String{m} -> String{lub l m}

send: phantom l. Socket{l} -> String{l} -> unit

send requires messages to be sent on sockets at the same security level

let sock:Socket{Low} = … inlet line1:String{Low} = … inlet line2:String{Low} = … in

send sock (strcat line1 line2)

String{lub Low Low} ~ String{Low}

let line1:String{Low} = … inlet line2:String{High} = … in

send sock (strcat line1 line2)

String{lub Low High} ~ String{High}

37

Information Flow in Fable

send: phantom l. Socket{l} -> String{l} -> unit

• Dynamic enforcement via type refinements

let sock:Socket{Low} = … in

line protected by label which is unknown statically

let label, line:String{label} = … in

Refine the type of line to String{Low}based on runtime check

match label with Low -> send socket line | High -> ()

Label Modification

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

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)

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

Modify Block Policy

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)

}

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)

}

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)

}