secure provenance policies in selinks
Skip this Video
Download Presentation
Secure Provenance Policies in SELinks

Loading in 2 Seconds...

play fullscreen
1 / 45

Secure Provenance Policies in SELinks - PowerPoint PPT Presentation

  • Uploaded on

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

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

PowerPoint Slideshow about 'Secure Provenance Policies in SELinks' - Gabriel

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

Secure Provenance Policies in SELinks

Michael Hicks

with Nikhil Swamy and Brian Corcoran

University of Maryland, College Park, USA

fable and selinks enforcing user defined security policies including provenance for web apps

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
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 languages shape of a solution
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
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 fable a type system for user defined security 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




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
Develop new libraries for new policies













Release Pol.










applications may use several policies
Applications may use several policies













the rest of the talk
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 labels associate data and policy
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
semantics of security labels an access control enforcement policy

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

access control in action

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
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
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
data provenance tracking

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))
data provenance tracking17

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))
  • }
protecting provenance information

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
a db schema in selinks

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”

accessing labeled db data

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

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



fine grained labeling of documents

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

| … |]);

label format

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

non observability correctness of access control

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 ]
executing selinks queries in the db

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’

information flow in fable

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}
information flow in fable36

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
information flow in fable37

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 modification39
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
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 code
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
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 policy45
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)
  • }