Secure provenance policies in selinks
1 / 45

Secure Provenance Policies in SELinks - PowerPoint PPT Presentation

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

Related searches for Secure Provenance Policies in SELinks

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

Download Presentation

Secure Provenance Policies in SELinks

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Secure Provenance Policies in SELinks

Michael Hicks

with Nikhil Swamy and Brian Corcoran

University of Maryland, College Park, USA

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

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.

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

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

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




The Fable approach, pictorially



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







Program 2


Program 3

Reuse library for several applications …

Develop new libraries for new policies













Release Pol.










Applications may use several policies













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

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

High integrity user credential.

Produced, say, by a login function

Data protected by acl

Check if cred is mentioned in the ACL


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

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


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 ;

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)

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

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

Policy tracks provenance through function application

A function tagged with provenance

Argument tagged with provenance

Unlabel before applying f to x




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

  • }

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

  • Implemented Fable as part of the Links web programming language

    • We call it “security-enhanced” Links

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”

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, /foo/)


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

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



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

| … |]);

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


  • 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

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


  • 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


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

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


CREATE FUNCTION access(text, record, anyelement)

RETURNS variant AS $$


$$ language ‘plpgsql’

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}

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

  • 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

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


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

    • }

  • Login