Poly stop a hacker David Walker Princeton University (joint work with Lujo Bauer and Jay Ligatti)

Poly stop a hacker

David WalkerPrinceton University

(joint work with Lujo Bauer and Jay Ligatti)

Poly stop a hacker David Walker

Language-Based Security

• language-based security mechanisms protect a host from untrusted applications analyzing or modifying application behavior– static mechanisms (analysis at link time)

• type checking, proof checking, abstract interpretation

– dynamic mechanisms (analysis at run time)• access-control lists, stack inspection, capabilities


Language-Based Security

• language-based security mechanisms protect a host from untrusted applications by analyzing or modifying application behavior– static mechanisms (analysis at link time)

• type checking, proof checking, abstract interpretation

– dynamic mechanisms (analysis at run time)• access-control lists, stack inspection, capabilities


Program Monitors

• A program monitor is a computation that runs in parallel with an untrusted application– monitors detect, prevent, and recover

from application errors at run time– monitor decisions may be based on

execution history – we assume monitors have no

knowledge of future application actions


Program Monitors: Good Operations

Application Monitor

fopen ()


Program Monitors: Bad Operations

Application Monitor

fopen () halt!


Program Monitors: Bad Operations

Application Monitor

fopen ()


Program Monitors: Options

• A program monitor may do any of the following when it recognizes a dangerous operation:– halt the application– suppress (skip) the operation but

allow the application to continue– insert (perform) some computation on

behalf of the application


Past Research

• Program monitors have a lengthy history in the systems community– OS kernels

• use hardware support• secure fixed system-call interface

– mobile code architectures and safe languages (Java, CLR)• more complex interactions between applications• more diverse set of interfaces to secure• more diverse set of policies necessary


The Polymer Project

• Theoretical analysis of the range of the policies enforceable at run time

• Definition and implementation of a high-level policy language– incorporate types, modularity and

high-level programming techniques

• Formal semantics and tools for reasoning about policies


Today: Polymer the Language

• Polymer via Pictures– simple policies– complex policies

• Polymer semantics– monadic structure– types

• Polymer discussion– implementation, related and future work


What is in a run-time security policy?

• Policy-relevant actions– method calls, get/set state, raise exception

• Security-relevant state– inaccessible to application program

• Decision procedure– does the current action satisfy the policy in

the current state?– if not, what supplementary action must be

taken?


Example: Access Control

a

Access Control Monitor (ACM)

fopenfclosegetcputc

actions

acl

state computation

acl lookup


Example: Deadlock Prevention

Deadlock Prevention Monitor (Deadlock)

acquire

release

actions

locksheld

state computation

locking protocol


Security in Complex Systems

• Restating the obvious:– it’s hard to secure complex systems against

the determined attacker

• Design goal:– prepare for mistakes– be ready for change

• Mechanisms:– modularity– highly structured and parameterized policies


Security in Complex Systems

• Polymer Mechanisms– high-level policy combinators

• conjunctive policies• disjunctive policies

– modularity mechanisms from modern languages (eg: ML)• hierarchical policies• parameterized policies• higher-order policies


Parallel Conjunctive PoliciesApplication ResourceMgr

conjunctive decision

DeadlockACM


Parallel Conjunctive Policies

• two independent parallel processes decide whether an action is allowed– both say okay ==> application goes ahead– either says halt ==> application halts– one says okay and the other does not care

about this action ==> application goes ahead

• example:– resourceMgr = ACM AND Deadlock


Policy Combinators

• Conjunctive policies narrow the set of acceptable program action sequences

• Disjunctive policies widen the set of acceptable program action sequences


Parallel Disjunctive PoliciesApplication ACM++

disjunctive decision

AuthenticatedACM

ACM


Parallel Disjunctive Policies

• two independent parallel processes decide whether an action is allowed– either says okay ==> app. goes ahead– both say halt ==> application halts– one says okay and the other does not

care about this action ==> app. goes ahead

• example:– ACM++= ACM OR AuthenticatedACM


Chinese Wall Policies

• Chinese Wall Policies– each application is offered a number

of protocol choices– when the application selects one

choice, all other choices become unavailable


Parallel Disjunctive PoliciesApplication Chinese Wall Monitor


NetworknotFile

FilenotNetwork


Complete Mediation

• A Crucial Security Principle– in order to protect a resource, one

must mediate all accesses to that resource

• Naive composition of policies can lead to violations of complete mediation– eg: kernelSafety AND deadlockinserts acquire/release

to protect kernel datamust see all acquire/release actions


Sequential Conjunction

Resource Manager

kernelsafety

deadlockprevention

Application



Sequential Conjunction

System Policy

resourcemanager logging/

auditingprocess

Application



Sequential Disjunction

Disjunctive MonitorApplication



Formal Language Structure

• Derived from the computational lambda calculus [Moggi]– computations (E)

• run in parallel with an untrusted application• have effects on the application (halt, suppress,

change state, perform application actions, etc.)

– terms (M)• an algebra for manipulating suspended

computations (ie: policies)• do not have effects


Simple Policies• actions (method calls)

– a in A

• terms (policies)– M ::= {actions: A; policy: E} | fun f (x:t) = M | M1 M2 | ...

• monitoring computations– E ::= M | ok; E | sup; E | call (a) next: E1 done: E2 | do M; E | case * of (A1: E1 | A2: E2) | ...


Memory-Limit Example

{ actions: malloc; policy: next: case * of malloc(n): let q’ = q-n in if (q’ > 0) then ok; do (mpol q’) else halt end done: ()}

fun mpol(q:int) =


Memory-Limit Policy

• mpol is a function from integers to policies

• to generate a policy we apply our function to an initial memory quota:– memLimit = mpol 10000


File-Access Example{ actions: fopen, fcloses; policy: next: case * of fopen(s,m): if (acl s m) then ok; do (fpol (s::files)) else sup; do (fpol (files)) | fcloses (l): ... done: call (fcloses files)}

fun fpol (files: file list) =


File-Access Policy

• Once again, we apply our recursive function to an initial argument to get a policy– fileAccess = fpol []


Policy Types

• types– t ::= int | () | t1 x t2 | t1 + t2 | t1 -> t2 |

M t

• examples:– mpol : int -> M ()– memLimit : M ()

• a simple type system prevents standard sorts of errors


Parallel Conjunctive Policies

• A parallel conjunctive policy is a suspended computation that returns a pair of values

• Types:– if P1 : M t1 and P : M t2 then P1 AND P2 : M (t1 x t2)– Curry-Howard strikes again!

• Trivial policy T is the identity for AND – T : M ()


Parallel Disjunctive Policies

• A parallel disjunctive policy is a suspended computation that returns a sum

• Types:– if P1 : M t1 and P : M t2 then P1 OR P2 : M (t1 + t2)

• Unsatisfiable policy is identity for OR : M void


Complete Mediation FailureApplication Monitor

foo () auditingprocessdeadlock


Conflicting PoliciesApplication Monitor

foo ()

?

oksup


Types and Effects

• We synthesize the effects of a computation– the effects = the actions that may be inserted or

suppressed by a computation

• P1 AND P2 is well-formed when– the effects of P1 are disjoint from the regulated

set of P2 and vice versa

• effect analysis – ensures complete mediation for parallel pol’s– provides flexibility in sequential pol’s


Implementation Architecture

Javaapplication

policyinterface

policyimplementation

instrumentedapplication

secure application


Implementation Progress

• work so far:– simple policies with basic features (ok, sup,

pattern matching, case, Java base)– higher-order policies and policy combinators

• future work:– networking applications– further combinators– type and effect system– dynamic policy updates


Related Work

• Aspect-oriented programming– Polymer is a domain-specific aspect-

oriented programming language– New features:

• an aspect algebra with novel combinators• a new approach to aspect collision (types

and effects)• formal semantics as an extension of

Moggi’s computational lambda calculus– see also Wand et al.’s semantics for aspects


Related Work

• Monitoring languages– General-purpose languages/systems

for monitoring applications• Poet and Pslang, Naccio, Ariel, Spin

Kernel

– Logical monitoring specifications• MAC (temporal logic), Bigwig (second-

order monadic logic)


Summary: Polymer

• First steps towards the design of a modern language for programming modular run-time security monitors

• References– FCS ‘02 (expressible and inexpressible

policies)– Princeton TR 655-02 (Polymer semantics)– www.cs.princeton.edu/sip/projects/polymer/


End

Poly stop a hacker David Walker Princeton University (joint work with Lujo Bauer and Jay Ligatti)

Documents

Transcript of Poly stop a hacker David Walker Princeton University (joint work with Lujo Bauer and Jay Ligatti)