Secure Provenance Policies in SELinks
Michael Hicks
with Nikhil Swamy and Brian Corcoran
University of Maryland, College Park, USA
1
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
2
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.
3
Security-typed Programming Languages
Shape 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
4
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
5
Our approach: Fable
A 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 typecorrect programs enjoy relevant security properties
– I.e., the policy is being enforced correctly
6
The Fable approach, pictorially
Access
Control
Library
Security
Proof
3. Design
Write program
that
1.
2.
Prove
that
format
this and
library
uses
this enforces
policy
- if it
correctly
semantics
for labels
typechecks
then
is
security
as
a library
policy
forittypesecure
correct programs
Type
correct?
SECURE
Application
Application
Application
Program
Program
Program23
Reuse library for several applications …
7
Develop new libraries for new policies
Security
Information
Information
Security
Access
Data
Proof
Release
Provenance
Automata
Control
Flow Pol.
Library
Type
correct?
SECURE
Application
Program
8
Applications may use several policies
Access
Control
Library
Security
Proof
Data
Provenance
Library
Security
Proof
Application
Program
9
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
10
Customizable Security Labels
Associate 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 = …
– int{l} y = …
– bool{Low} z = …
// unprotected data
// protected by label l
// 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
11
Semantics of Security Labels
An Access Control Enforcement Policy
High integrity user credential.
Produced, say, by a login function
a list, e.g., [uid1; uid2; …]
Data protected by acl
-> α -> String
String{acl})
sig access : (Cred{High}, acl<-Acl, α{acl})
policy keyword identifies
fun access (cred, acl, data) policy {
this code as privileged
if member (cred, acl) then
unlabel (data)
Check if cred is mentioned in the ACL
else error(“access denied”)
}
String
α
Success: unlabel data and expose to application code
Only policy code can destruct a labeled value
12
Access Control in Action
access: (UserCred{High},x<-Acl,String{x}) -> String
readline: phantom l. File{l} -> String{l}
String logged
-> unit in
Credential ofprintstr:
user currently
“Phantom” label polymorphism
var user:UserCred{High} = login … ;
var (acl:Acl, fh:File{acl}) = open_in “f.txt” ;
var (acl2:Acl, f2:File{acl2}) = open_in “f2.txt” ;
var line:String{acl} = readline fh ;
printstr (access (user,acl,line)) ;
Open file: get acl and file handle
printstr line ;
printstr (access(user,acl2,line)) ;
And must be the
right check
Must call policy authorization
Infer instantiation of label variable
String{acl2}
String{acl}
check before
printing -> String
13
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)
14
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
15
Data Provenance Tracking
Objective: track dependences in the label associated
with the result of a computation
A dependently typed pair
containing the provenance
metadata l and the data α
Representation of
provenance tracked 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))
Tag with provenance
of both x and y
Computation depends
on both x and y
16
Data Provenance Tracking
typename Prov α = (l<-ProvLab,α{l})
Policy tracks provenance through function application
A function tagged with provenance
Argument tagged with provenance
Split
each
pair
sig apply (Prov (α -> β), Prov α) -> Prov β
fun apply (lf, mx) policy {
var (l, f) = lf ;
Unlabel before applying f to x
var (m, x) = mx ;
var result = unlabel(f)(unlabel(x)) ;
var l_result = Union(l, m) ;
(l_result, label(result, l_result))
}
Return type: Prov β
Provenance of result, includes provenance of f and x
17
Protecting Provenance Information
Protect the provenance label
with its own security policy
typename typename
Prov α = (l<-ProvLab{Acl(Admins)},
Prov α = (l<-ProvLab,α{l}α
) {unlabel l})
var l = File “secret.txt” ;
(label(l,
(l, label(“secret
Acl(Admins)),
data”, label(“secret
l))
data”, l))
Provenance data can itself be confidential
18
• Implemented Fable as part of the Links web
programming language
– We call it “security-enhanced” Links
19
A DB Schema in SELinks
• Every DB table is given an SELinks type
– Types can include label dependences
Table name
table “labeled_doc” with =
Custom datatype extensions
(id : Int,
allow SELinks values to be
acl: Acl,
stored in DB (implemented
data : String{acl})
for Postgres and Oracle)
from database ”db”
1st column is the primary key
2nd column is a label that protects the
data in the 3rd column
20
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;
For each row
in the table
var result =
for (row <-- ld)
where (access (cred, row.label, row.data) ~
/foo/)
[row];
Result is a list of all rows that
satisfy the where-clause
Where-clause checks access
control policy, compiled to
stored DB proc, to inspect data
21
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
22
Overview of SEWiki
A document with Record provenance:
components at different
revision history etc.
security levels
server
client
Filter
saves changes
out part of document
not accessible to this user
Edits content in visible
part of document
23
24
25
Fine-grained Labeling of Documents
Documents are n-ary trees
with with words at the leaves
A dependently typed pair
typename Block = mu block.
([| Word: String
| Compound: [block]
| Labeled: (l<-Label, block{l})
| … |]);
Some subtrees can
be protected
by a security label
First component a label l that protects
the subtree in the second component
26
Label Format
Labels may have an access control
and a provenance component
typename Label = mu label.
[| Composite: [label]
| Acl: (read:[Group], write:[Group])
Provenance
| Prov: [ProvAction]
used to track
|];
document
modifications
typename ProvAction = (
oper: ProvOp, user: Group, … );
typename ProvOp =
[| Create | Modify | Relabel
| Copy | Delete | Restore |];
27
28
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
29
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
30
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
31
EXTRA SLIDES
32
Non-Observability
Correctness of Access Control
• Given an application e with x protected by some acl
u:UserCred{High}, x:bool{acl} |- e : t
• And the user Alice is not authorized to access x
member Alice acl -->* false
• 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 ]
33
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)
SQL compiled
from
list comprehension
CREATE FUNCTION access(text, record, anyelement)
RETURNS variant AS $$
Stored proc. compiled
DECLARE … BEGIN … END;
from enforcement policy
$$ language ‘plpgsql’
34
Information Flow in Fable
• Static enforcement via type conversions
lub just a user-defined function
let lub _ High = High
lub High _ = High
lub _
_ = Low
Concat’d string at
least as confidential
as the arguments
strcat: phantom l,m. String{l} -> String{m} -> String{lub l m}
String{lub Low High} ~ String{High}
Type checker can reduce these
expressions to show type equivalence
35
Information Flow in Fable
• Static enforcement via type conversions
strcat: phantom l,m. String{l} -> String{m} -> String{lub l m}
send requires messages to be sent on
sockets at the same security level
send: phantom l. Socket{l} -> String{l} -> unit
let sock:Socket{Low} = … in
let line1:String{Low} = … in
line2:String{Low} ==……inin
let line2:String{High}
send sock (strcat line1 line2)
String{lub Low Low}
High}~~String{Low}
String{High}
36
Information Flow in Fable
• Dynamic enforcement via type refinements
send: phantom l. Socket{l} -> String{l} -> unit
let sock:Socket{Low} = … in
let label, line:String{label} = … in
match label with Low -> send socket line
line protected by label which | High -> ()
Refine the type of
is unknown statically
line to String{Low}
based on runtime
check
37
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)
}