Poly stop a hacker

1
Poly stop a hacker

• David Walker
• Princeton University
• (joint work with Lujo Bauer and Jay Ligatti)

2
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

3
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

4
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

5
Program Monitors Good Operations
Monitor
Application
fopen ()
6
Program Monitors Bad Operations
Monitor
Application
halt!
fopen ()
7
Program Monitors Bad Operations
Monitor
Application
fopen ()
8
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

9
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

10
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

11
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

12
Today Polymer the Language

• Polymer via Pictures
• simple policies
• complex policies
• Polymer semantics
• monadic structure
• types
• Polymer discussion
• implementation, related and future work

13
Today Polymer the Language

• Polymer via Pictures
• simple policies
• complex policies
• Polymer semantics
• monadic structure
• types
• Polymer discussion
• implementation, related and future work

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

15
Example Access Control
Access Control Monitor (ACM)
a
state
actions
computation
fopen fclose getc putc
acl
acl lookup
16
Example Deadlock Prevention
Deadlock Prevention Monitor (Deadlock)
state
actions
computation
acquire release
locks held
locking protocol
17
Security in Complex Systems

• Restating the obvious
• its 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

18
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

19
Parallel Conjunctive Policies
ResourceMgr
Application
Deadlock
ACM
conjunctive decision
20
Parallel Conjunctive Policies

• two independent parallel processes decide whether
  an action is allowed
• both say okay gt application goes ahead
• either says halt gt application halts
• one says okay and the other does not care about
  this action gt application goes ahead
• example
• resourceMgr ACM AND Deadlock

21
Policy Combinators

• Conjunctive policies narrow the set of acceptable
  program action sequences
• Disjunctive policies widen the set of acceptable
  program action sequences

22
Parallel Disjunctive Policies
ACM
Application
Authenticated ACM
ACM
disjunctive decision
23
Parallel Disjunctive Policies

• two independent parallel processes decide whether
  an action is allowed
• either says okay gt app. goes ahead
• both say halt gt application halts
• one says okay and the other does not care about
  this action gt app. goes ahead
• example
• ACM ACM OR AuthenticatedACM

24
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

25
Parallel Disjunctive Policies
Chinese Wall Monitor
Application
Network not File
File not Network
disjunctive decision
26
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 deadlock

inserts acquire/release to protect kernel data
must see all acquire/ release actions
27
Sequential Conjunction
Application
Resource Manager
deadlock prevention
kernel safety
conjunctive decision
28
Sequential Conjunction
Application
System Policy
resource manager
logging/ auditing process
conjunctive decision
29
Sequential Disjunction
Application
Disjunctive Monitor
disjunctive decision
30
Today Polymer the Language

• Polymer via Pictures
• simple policies
• complex policies
• Polymer semantics
• monadic structure
• types
• Polymer discussion
• implementation, related and future work

31
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

32
Simple Policies

• actions (method calls)
• a in A
• terms (policies)
• M actions A policy E
• fun f (xt) 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) ...

33
Memory-Limit Example
actions malloc policy next case
of malloc(n) let q q-n in
if (q gt 0) then ok do (mpol q) else
halt end done ()
fun mpol(qint)
34
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

35
File-Access Example
actions fopen, fcloses policy next
case of fopen(s,m) if (acl s m)
then ok do (fpol (sfiles))
else sup do (fpol (files))
fcloses (l) ... done call (fcloses
files)
fun fpol (files file list)
36
File-Access Policy

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

37
Policy Types

• types
• t int () t1 x t2 t1 t2 t1 -gt t2
  
• M t
• examples
• mpol int -gt M ()
• memLimit M ()
• a simple type system prevents standard sorts of
  errors

38
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 ()

39
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

40
Complete Mediation Failure
Monitor
Application
foo ()
auditing process
deadlock
41
Conflicting Policies
Monitor
Application
foo ()
sup
ok
?
42
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 pols
• provides flexibility in sequential pols

43
Today Polymer the Language

• Polymer via Pictures
• simple policies
• complex policies
• Polymer semantics
• monadic structure
• types
• Polymer discussion
• implementation, related and future work

44
Implementation Architecture
Java application
policy interface
policy implementation
instrumented application
secure application
45
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

46
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 Moggis
  computational lambda calculus
• see also Wand et al.s semantics for aspects

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

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

49
End