Nikhil Swamy Joint work with Juan Chen and Ravi Chugh

Nikhil Swamy http://research.microsoft.com/fine

Joint work with Juan Chen and Ravi Chugh

Fine and DCILSecure programming on .NET

http://research.microsoft.com/fine

2

Secure distributed programming Users download code to browser, phone, etc. Also upload programs to cloud– JavaScript, Flash, Silverlight, Java, .NET, Python, …– Mostly memory-safe languages

But, memory safety is not enough for security– Browser+extensions still enforces Same-Origin Policy? – Is entire cloud-hosted DB visible to a user program?

Want automated security verification

3

Security-typed programming Language support for security verification Prove software secure by construction

15+ years of research producing MANY Models of secure computation Policy languages Typing disciplines

Which model, policy language and type system to pick for secure cloud computing?

4

What’s your favorite flavor?

5

Flavors of security

Information flow Label model? Atomic, decentralized, role-based, … Explicit flows + implicit flows? Explicit only? Termination (in)sensitive?

Plus declassification Many dimensions, many flavors in each dimension …

Access control But which authorization logic? XACML, SecPAL, DKAL, DCC, SD3, Binder, Ponder, RT, … Stateless, history-based, ...

Auditing Cryptographic evidence? Explicit proof terms?

7

Which flavors to bake into a language?

The answer in Fine: None

Instead A few general purpose constructs Flexible enough to capture many security idioms

8

What is Fine?A subset of F# with a type system designed around

Value-indexed typessecretString: labeled<string, High>

Dependent refinement typesgetEmail: p:plugin -> {e:email | CanRead p e } -> string

Affine (use-at-most-once) types– Useful for modeling state

9

Why Fine? Why not Coq, Agda, …?

10

DCIL: Type system for .NET bytecode The target language for the Fine compiler– Fine to DCIL translation is type-preserving

DCIL backwards compatible with CIL

Fine’s type system carefully designed to match what is possible TODAY on the .NET VM

Coq, Agda, even Haskell, can’t be compiled to .NET (with high fidelity)

11

Example applications Lookout: A model of a plugin-based email client

– Verify that .NET DLLs for plugins:• Respect user’s authorization policy • Never leak email from one contact to another

HealthWeb: A model health-record mgmt. website on Windows Azure– Web interface in ASP.NET and C#– Data tier in F#/SQL Server– Reference monitor for data tier verified using in Fine

Currently underway– Secure browser extensions for IE– Secure program marshaling – Crypto protocol verification

12

Plan A brief primer on Fine, the structure of our

compiler, and experiments

A more in-depth look at – Information flow – Stateful authorization

Demo: Fine + DCIL on Azure

Wrap up

13

Specifying and enforcing XACML policies<Resource> <ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"><ResourceAttributeDesignator AttributeId="resource:datastream:id“ DataType=“…/XMLSchema#string"/><AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">PatientRecord</AttributeValue> </ResourceMatch></Resource> <Action> <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">action:getData</AttributeValue> </Action><Subject> <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Doctor</AttributeValue> </SubjectMatch> </Subject><Rule RuleId="1" Effect="Deny"> <Target> … </Target> <Condition> ... </Condition> </Rule> <Rule RuleId=“2" Effect=“Permit"> <Target> … </Target> <Condition> ... </Condition> </Rule>

XACML Policy

public Data GetData (string subjectName, string recId) { Record rec = DB.GetRecord (subjectName, recId); List queryParams = new {subjectName, rec.datastreamId}; if (XACML.GetAuthCtxt(subjectName).query(“CanGetData”, queryParams)) { return rec.data; } return null;}

C# code that mediates access to patient records

Current practice

Complete mediation? Is this the right query with right parameters?Does this code properly enforce the policy?

Resources: patient-records

Actions: getData, …

Subjects: Doctors, …

Rules: Grant, Deny, …

14

Fine: Specify and enforce security policies

val readRecord: p:prin -> cred -> {r:record | HasPerm<p, CanRead r>} ->

string

assume Rule_docCanRead: forall p:prin, r:record. (InRole<p,Doctor> && Treating<p, r.patient>) => HasPerm<p, CanRead r>assume …

A reference monitor written in Fine

Type checker ensures authenticity, complete mediation, information hidingThe type of a function to read

data from a protected record

Policy specified using logical formulas in a header file

Types mention security constraints from policy

15

module RequestMgr

let rec hdlreq () = match next_request () with | p, cred, GetRecordContents r ->

let test = checkRole p Doctor &&checkTreating p

r.patient in if test then let record_data =

HealthDB.readRecord p cred r in

respond record_data;hdlreq ()

elserespond (Denied “Sorry, insufficient

privilege”);evtloop ()

Security verification by type checking

Type error RequestMgr.fine (9.10) – (9.43): Expected {r:record | HasPerm <p, CanRead r>}Got record

Query the policy

Read records only if test succeeds

16

Structure of our compilerFine: Functional language with refinement typesgetEmail: p:plugin -> {e:Email | CanRead<p,e> } -> stringFine

DCIL: Type system for functional core of .NET bytecode• Purely syntactic verification (solver not in TCB)• Verification is fast • Executable on stock .NET VM

Z3 Type-checker + Compiler

DCIL

DCIL Type-Checker

Type-checked using Z3 (SMT solver) • Simplifies programming • Extract typeable proof terms from Z3• Proofs flexible for a variety of logics

.NET Virtual Machine

C#, F#,… DCIL

17

Reference monitors for example programs

An interpreter for (a fragment of) the DKAL authorization logic -- Refinements ensure that substitutions of quantified assumptions are correct

A module implementing a lattice-based information flow policyAn automaton based policy for access control on files -- similar to typestate tracking

A reference monitor for a filesystem that tracks and rules out illegal information flows between files

18

Reference monitors for example programs

Lookout: A plugin-based email client -- plugins subject to a stateful authorization and information flow tracking policy

A model of the Continue conference management server -- Stateful authorization policy structured into 9 phases, 12 kinds of actions

An auto-generated library of commonly used proofs and lemmas -- verified by pure type checking alone, no use of Z3

A model of HealthVault, a website for managing a database of a health records

Web interface in ASP.NET and C#Back end in F# and a SQL Server database

Too many proof terms to write by hand. Automation via Z3 is key.

Reference monitors are compact. No need to write your whole application in Fine.

19

Translating to DCIL

Preliminary experiments with SS a custom proof-producing first-order prover yield 25x improvement

Increase in code size with Z3 proof: 50xIncrease in code size with SS proof: 2x

Increase in code size 2x – 50x Z3 often produces very verbose proofs

Compilation times are still high. Includes time spent in Z3, and extracting and verifying proof terms

Verifying DCIL programs is fast. Syntax directed verification of programs and proofs

20

Security verification for mobile code Translation validation for Fine compiler

Proof-carrying and code-carrying authorization (Appel & Felten; Maffeis et al.)

Verifiable audit trails (Zdancewic et al.)

– Log proof terms in support of post-hoc reconstruction of authorization decisions

Secure marshaling– DCIL as a verifiable serialization format

Benefits of compiling with proofs

21

Plan A brief primer on Fine, the structure of our

compiler, and experiments

A more in-depth look at – Simple access control– Information flow – Stateful authorization


Wrap up

22

Fine: Simple access control on files Develop a reference monitor for a file system– Enforces a simple access control policy

Main idea: Give privileged operations refined types to capture their pre- and post-conditions

Type check reference monitor to ensure that every call of fread is protected by a suitable check

val fread: p:prin -> credential -

> {f:file |

CanRead<p,f> } -> string

Principal p authenticated by this credential

The type of file handles f for which the (CanRead<p, f>) proposition is valid

23

Fine: Simple access control on filestype filetype prin = Alice | Bob | Admintype credential<prin>

val login: p:prin -> pw:string -> option<credential>type CanRead<prin,file>

assume AdminCR: forall (f:file). CanRead<Admin, f>assume AliceCR: …

val fread: p:prin -> credential -> {f:file | CanRead<p,f> } -> string

credential is a value-indexed typecredential<Alice> is the type of a credential authenticating Alice. Types ensure that this cannot be confused as a credential for Bob.

login has a dependent function typeConstructs a credential for p if the password check succeeds

The CanRead predicate is a binary type constructor

A policy is specified using a series of first-order logic assumptions

24

Simple access control on filesmodule FileSystemRMtype CanRead<prin, file> type CanWrite<prin, file>

val fread: p:prin -> cred -> {f:file | CanRead<p,f> } -> string

val fwrite: p:prin -> cred -> {f:file | CanWrite<p,f> } -> string ->

unit

But, this API does not prevent a privileged client from copying data from a secret file into a publically visible file

25

Tracking information flows between filestype label = File: file -> label

| Join: label -> label -> labeltype tracked<‘a, label>type CanFlow<label,label>assume Atomic_flow: forall f:file, g:file. (forall p:prin. CanRead<p,g> => CanRead<p,f>) => CanFlow<File f, File g>assume Lattice: …

val fread: p:prin -> cred -> f:{x:file | CanRead<p,x>} ->

tracked<string, File f>val fwrite: p:prin -> cred -> f:{x:file | CanWrite<p,x>} -> l:{x:label | CanFlow<x, File f>} -> data:tracked<string, l> -> unit

tracked<t, q> data of type t originated from files in q

Returned data tagged with label f

Data allowed to flow to f

26

Tracking flows in client programs View tracked<‘a,label> as a lattice of monads (or applicative functors)

– Abadi et al. in DCC

bind: l:label -> tracked<(‘a -> ‘b), l> -> m:label -> tracked<‘a, m> ->

tracked<‘b, Join l m>

More effort: programmers use bind explicitly

Apply a labeled function

To a labeled argument

Result at least as secret as both

27

Plan A brief primer on Fine and the structure of our

compiler

A more in-depth look at – Simple access control– Information flow – Stateful authorization in ConfWeb


28

ConfWeb: A conference mgmt. tool Based on Continue: Krishnamurthi et al. – A conference management server in PLT Scheme

Privileges granted by the policy evolve over time

Policy structured into 9 phases, 12 kinds of permissions, ~ 50 rules in policy– “Almost all interesting bugs in Continue have related

to access control in some form”--- Krishnamurthi et al. IJCAR 2006

29

Implemented in Fine

Authenticationmodules

Database of papers,

reviews, …

Untrusted application code (in F#)

Structure of ConfWeb

Reference monitor provides authorized access to database

Security Policy

Chair

Author

Reviewer

A model of stateful authorization

30

AuthState s0

(Role (U “Andy”) Chair)(Phase Submission)

assume canReview: forall u:prin, p:paper, s:authstate. (In (Role u Reviewer) s && In (AssignedPaper p u) s) => GrantedIn (Permit u (Review p)) s…

AuthState s1

State transition on eventCloseSubmissions

AuthState s2

State transition on eventAssignPaper paper17 Bob

Authorization policies are defined over an evolving set of relations (authorization attributes)

Policies specify an unchanging set of inference rules to derive authorization facts from the current authorization state

(Role (U “Andy”) Chair)(Phase PaperAssignment)

(Role (U “Andy”) Chair)(Phase PaperAssignment)(AssignedPaper paper17 (U “Bob”))

31

A simple data model for ConfWebmodule ConfWeb

type paper = {id:int; authors:list prin; contents:string; … }

type review = {paperid:int; reviewid:int; author:prin; …}

type db = list<paper> * list<review> * authstate * …

Stateful authorization in ConfWeb(1)

32

A vocabulary for a security policytype role = Author | Reviewer | Chair | …type phase = Submission | Assignment | Meeting | …type attr = Role: prin -> role -> attr | Assigned: prin -> paper -> attr | Phase : phase -> attrtype authstate = list<attr>

type action = Submit: paper -> action | Review: paper -> action | ReadScore: paper -> action | CloseSub: action

type permission = Permit: prin -> action -> permission

prop In<attr, authstate>prop GrantedIn<permission, authstate>


Authorization state is a list of authorization attributes

Role memberships, paper assignments, conference phase … Permit Alice (Submit p)

GrantedIn <q, s> says that permission q is derivable from the authstate s

33

assume canSubmit: forall u:prin, p:paper, s:authstate. (In<Role u Author, s> && In<Phase Submission, s>) => GrantedIn<Permit u (Submit p), s>

assume canCloseSubmissions: forall u:prin, s:authstate. (In<Role u Chair, s> && In<Phase Submission, s>) => GrantedIn<Permit u (CloseSub), s>

assume canReview: forall u:prin, p:paper, s:authstate. (In<Role u Reviewer, s> && In<Assigned u p, s>) =>

GrantedIn<Permit u (Review p), s>

…

A security policyStateful authorization in ConfWeb(3)

Security policies are stated using assumptions in the form of first-order logic formulas

34

Connecting policy to code using types

val submit_paper: u:prin -> credential -> p:paper ->

{s:authstate | GrantedIn<Permit u (Submit p), s>} ->

unit


Calling principal u authenticated using this credential

Prove that u has the Submit p permission in the authstate s

35

Connecting policy to code using types



unit

val close_submissions:u:prin -> credential -> {s:authstate | GrantedIn<Permit u

CloseSub, s> } -> {s’:authstate | In<Phase Assignment, s’> }


Pre-condition: u must have the CloseSub permission in the pre-state s

Post-condition: (Phase Assignment) is in the post-state s’

36

Modeling state changes with affine types



unit




s is a stale state. Want to ensure that facts derived from s are unusable in subsequent authorization decisions.

37

Modeling state changes with affine typestype StateIs :: authstate => A val submit_paper: u:prin -> credential -> p:paper ->


unit




A is the kind of affine typesStateIs constructs an affine type from an authstate value

38

Modeling state changes with affine typestype StateIs :: authstate => A val submit_paper: u:prin -> cred u -> p:paper ->

s:{s:authstate | GrantedIn<Permit u (Submit p), s>} ->

StateIs<s> -> StateIs<s>




A is the kind of affine typesStateIs<s> is the type of a token asserting s is the current state

Leaves the state unchanged

39


s:{s:authstate | GrantedIn (Permit u (Submit p)) s} ->

StateIs<s> -> StateIs<s>

val close_submissions:u:prin -> cred u ->

s:{s:authstate | GrantedIn<Permit u CloseSub, s> } ->

StateIs<s> -> (s’: {s’:authstate | In<Phase Assignment, s’>} * StateIs<s’>)


Leaves the state unchanged

Consumes a (StateIs s) token. Produces a (StateIs s’)

token.

40


s:{s:authstate | GrantedIn (Permit u (Submit p)) s} ->

StateIs s -> StateIs s

val close_submissions:u:prin -> cred u ->

s:{s:authstate | GrantedIn (Permit u CloseSub) s} ->

StateIs s -> (s’:{s’:authstate | In (Phase Assignment) s’} * StateIs s’)


Kinding rules forbid affine values from appearing in formulas. I.e, in t => A, the type t has to be non-affine


41

contains: a:attr -> s:authstate -> {b:bool | b=true <=> In a s}

let rec evtloop (s, sTok) = match next_request () with | u, cred, SubmitPaper p ->

let test = contains (Role u Author) s &&contains (Phase

Submission) s in if test then let sTok = submit_paper u cred p s sTok in respond (“Submission received”);

evtloop (s, sTok) else

respond (“Request denied”);evtloop (s, sTok)

| u, cred, CloseSubmissions -> let test = contains (Role u Chair) s &&

contains (Phase Submission) s in

…

Handling application requestsStateful authorization in ConfWeb(6)

Type error RequestMgr.fine (6.10) – (6.43): Expected {s:authstate | GrantedIn <Permit u (Submit p), s> }Got authstate

42

Plan A brief primer on Fine and the structure of our

compiler

A more in-depth look at – Simple access control– Information flow – Stateful authorization in ConfWeb


Patient

Doctor

Insurance provider

SQLAzure

consentread

searchread

search

Security Policy

UI

App logic

Reference monitor

p InRole Doctor ANDp IsTreating r.patient => p CanRead r

GetRecords

ASP.NET/C#

DB_select

Fine F#

O/R Mapping

Client(Web browser)

Application(Azure Web Role)

Database(SQL Azure)

Type of enforcement codeLogical rules for security policy

GetRecords: p: prin -> List< {r:record| CanRead <p,r>} >

Demo: HealthWeb on Azure

44

http://fine-healthweb.cloudapp.net

http://fine-healthweb.cloudapp.net/

45

Summary

Fine Many different flavors of security-typed programming Using a few general-purpose primitives

DCIL Security verification at the bytecode level

Secure distributed computing – Clients and the cloud

46

In progress

FX: Hoare triples for programming with affinity– A higher-level surface language for Fine

Secure browser extensions using Fine and DCIL– IE and the RiSE Cloud Computing Client (C3)

Combining cryptographic proofs with proof-carrying code– Fine + F7 (MSR Cambridge)

With Juan Chen, Karthik Bhargavan , Johannes Borgstroem, Cedric Fournet, Arjun Guha, Ben Livshits, Alok Rai, Jean Yang

47

Try it out

fine-0.3-alpha: Compiler sources, example programs



Nikhil Swamy Joint work with Juan Chen and Ravi Chugh

Documents

Transcript of Nikhil Swamy Joint work with Juan Chen and Ravi Chugh