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
Fable (and SELinks) Enforcing User-defined
Security Policies (including provenance) for Web
Apps
or

• 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
  languages types
• E.g., annotate a type with a security level from
  an MLS security policy intsecret vs.
  intpublic
• 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
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
• lab l High
• lab m ACL(nswamy,bjc,mwh)
• Protected data refers to its label in its type
• int x // unprotected data
• intl y // protected by label l
• boolLow z // protected by label Low
• In general, protected data has a dependent type
  te
• 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 (CredHigh, acllt-Acl,
• fun access (cred, acl, data) policy
• if member (cred, acl) then
• unlabel (data)
• else error(access denied)

?acl) -gt ?
Stringacl) -gt String
13
Access Control in Action
access (UserCredHigh,xlt-Acl,Stringx) -gt
String
readline phantom l. Filel -gt Stringl
printstr String -gt unit

• var userUserCredHigh login
• var (aclAcl, fhFileacl) open_in f.txt

var lineStringacl 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
Data Provenance Tracking

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

typename Prov (?) (llt-ProvLab, ?l)
var xProv int (Alice, label(0,Alice)) var
yProv int (Bob, label(1,Bob))
var l Union(Alice,Bob) (l, label(xy, l))
17
Data Provenance Tracking
typename Prov ? (llt-ProvLab,?l)
sig apply (Prov (? -gt ?), Prov ?) -gt 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
Protecting Provenance Information
typename Prov ? (llt-ProvLabAcl(Admins),?unlab
el l)
typename Prov ? (llt-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
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 Stringacl) from database
db
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 lt-- 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
Overview of SEWiki
server
client
24
(No Transcript)
25
(No Transcript)
26
Fine-grained Labeling of Documents

typename Block mu block. ( Word String
Compound block Labeled (llt-Label,
blockl) )
27
Label Format

typename Label mu label. Composite
label Acl (readGroup, writeGroup)
Prov ProvAction
typename ProvAction ( oper ProvOp, user
Group, ) typename ProvOp Create
Modify Relabel Copy Delete Restore
28
(No Transcript)
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
Non-ObservabilityCorrectness of Access Control

• Given an application e with x protected by some
  acl uUserCredHigh, xboolacl - e t

• Then, executions with xtrue and xfalse are
  identical
• ex -gt true, u -gt Alice --gt e x -gt true, u
  -gt Alice
• ltgt
• ex -gt false, u -gt Alice --gt e x -gt false,
  u -gt 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
35
Information Flow in Fable

• Static enforcement via type conversions

strcat phantom l,m. Stringl -gt Stringm -gt
Stringlub l m
Stringlub Low High StringHigh
36
Information Flow in Fable

• Static enforcement via type conversions

strcat phantom l,m. Stringl -gt Stringm -gt
Stringlub l m
send phantom l. Socketl -gt Stringl -gt unit
let sockSocketLow in
let line1StringLow in let
line2StringLow in
let line1StringLow in let
line2StringHigh in
37
Information Flow in Fable

• Dynamic enforcement via type refinements

send phantom l. Socketl -gt Stringl -gt unit
let sockSocketLow in
let label, lineStringlabel 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)-gtDoc,
Path, Pagel) -gt Pagel fun applyWriteToBlock(cr
ed, f, path, page) policy var (l, oldBlk)
getBlock(cred, page, path) var newBlk
applyWrite(cred, f, l, oldBlk) dbreplaceBlock(cre
d, oldBlk, newBlk)