Policy Enforcement via Program Monitoring

1
Policy Enforcement via Program Monitoring
Jay Ligatti (Princeton) joint work with Lujo
Bauer (CMU), David Walker (Princeton)
2
Security Policy Enforcement

• News flashSoftware sometimes does bad stuff
• Bugs
• Malicious design
• One mitigation is run-time monitoring
• Ensure that software adheres to run-time
  constraints specified by a security policy
• Stack inspection, access-control lists, applet
  sandboxing, firewalls, resource monitors,

3
Run-time Program Monitors
Untrusted Target
Program Monitor
Executing System
Open(f,w)
Open(f,w)
Open(f,w) is OK

• Monitors enforce policies by
• Interposing between untrusted code and the
  system executing the untrusted code
• Making sure only legal code is executed

4
Policies Become More Complex

• As software becomes more sophisticated
• Multi-user and networked systems
• Electronic commerce
• Medical databases (HIPAA)
• As we tighten overly relaxed policies
• Insecure default configurations disallowed
• Downloading .doc files requires warning
• As we relax overly tight policies
• All applets sandboxed (JDK 1.0) vs. only
  unsigned applets sandboxed (JDK 1.1)

5
Research Questions/Goals

• What are the limits of program monitors?Which
  policies can they enforce?
• Understanding limits can save us from trying to
  enforce policies with insufficiently strong
  mechanisms
• Also helps us choose best mechanism to enforce
  policy at hand
• How should we design a language in which to write
  complex and dynamic policies?

6
Outline

• Motivation
• Which policies can monitors enforce?
• Language for writing complex policies?
• Delineating the enforceable policies
• Formally define monitor enforces a policy
• Analysis of enforcement powers
• A language for writing complex policies
• Handle complexity with composition
• Polymer language
• Summary

7
Local Roadmap
1. Define policies (and properties) on systems
2. Define monitors and their operational semantics
3. Define enforcement of a policy by a monitor
8
Systems and Executions

• System a state machine that transitions states
  by executing actions
• We specify a system according to the possibly
  countably infinite set of actions it can execute
• A open f, close f (where f is any file
  name)
• Execution possibly infinite sequence of actions
  
• open f close f
• open f1 close f1 open f2 close f2

9
Execution Notation

• On a system with action set A, A set of all
  finite executions A? set of all infinite
  executions A8 set of all executions
• The empty sequence (execution) is ?
• The concatenation of sequences s and u is su
• Prefix notation su (or us)
• Means s is a finite prefix of possibly infinite
  u
• Read s prefixes u (or u extends s)

10
Policies Schneider 00

• Policy predicate P on sets of executions
• Set of executions S Í A8 satisfies P iff P(S)
• Termination policy
• P(S) iff every execution in S is finite
• Key uniformity policy
• P(S) iff the cryptographic keys used in all
  executions in S form uniform distribution

11
Properties Schneider 00

• Policy P is a property iff predicate p on
  executions such that "S Í A8 , P(S) Û "uÎS
  p(u)
• Properties cannot specify relationships between
  executions
• Termination is a property
• Key uniformity is not a property
• Monitors in our model only see individual
  executions, so they enforce properties

12
Safety and Liveness Lamport 77 Alpern,
Schneider 85

• Two types of properties have been studied a lot
• Safety Bad executions cannot be made good
• "sÎA8 Øp(s) Þ ss "us Øp(u)
• Access-control (cannot undo illegal accesses)
• Liveness Finite executions can be made good
  "sÎA us p(u)
• Termination and nontermination

13
Local Roadmap
1. Define policies (and properties) on systems
2. Define monitors and their operational semantics
3. Define enforcement of a policy by a monitor
14
Operation of Monitors Accepting an OK Action
Untrusted Target
Program Monitor
Executing System
Open(f,w)
Open(f,w)
Open(f,w) is OK
Monitor inputs actions from target and outputs
actions to the executing systemHere, input
action is safe to execute, so monitor accepts it
(makes it observable)
15
Operation of Monitors Suppressing an Action
Untrusted Target
Program Monitor
Executing System
Open(f,w)
Open(f,w) is not OK
Input action is not safe to execute, so monitor
suppresses it and allows target to continue
executing
16
Operation of Monitors Inserting an Action
Untrusted Target
Program Monitor
Executing System
Open(f,w)
Close(f,w)
Open(f,w) is not OK
Input action is not safe to execute, so monitor
inserts another action, then reconsiders the
original action
17
Modeling Monitors

• Model a monitor that can accept, suppress, and
  insert actions as an edit automaton (Q,q0,t)
• Q is finite or countably infinite set of states
• q0 is initial state
• A complete, deterministic, and TM-decidable
  function

t Q x A Q x (A U ?)
suppress trigger action
current state
input (trigger) action
new state
action to insert
18
Operational Semantics

• A monitors transition function defines how it
  behaves on individual input actions
• For the definition of enforcement, we need to
  consider the way monitors transform entire input
  executions

Monitors are execution transformers
Valid output
Untrusted input
a1a2a2a3
a1a2a2a4
Monitor
19
Operational Semantics Judgments

• Desired judgment (q0,s) X ß u
• Automaton X starting in state q0 transforms input
  sequence s into output sequence u
• Build up to this judgment
• 1. Single-step judgment (q,s) X u (q,s)
• 2. Multi-step judgment (q,s) X Þu (q,s)
• 3. Transforms judgment (q0,s) X ß u

20
Local Roadmap
1. Define policies (and properties) on systems
2. Define monitors and their operational semantics
3. Define enforcement of a policy by a monitor
21
Effective Enforcement

• Effective enforcers adhere to two principles
• Soundness
• Monitors outputs (i.e., observable executions)
  must satisfy the desired property
• Transparency
• Monitors must not alter the semantics of valid
  inputs
• Conservative definition on a valid input
  sequence s, a monitor must output s

22
Enforcing Properties

• Automaton X starting in q0 enforces p on a system
  with action set A iff "sÎA8 uÎA81. (q0,s) X
  ß u2. p(u) Soundness3. p(s) Þ
  (su) Transparency

23
Outline

• Motivation
• Which policies can monitors enforce?
• Language for writing complex policies?
• Delineating the enforceable policies
• Formally define monitor enforces a policy
• Analysis of enforcement powers
• A language for writing complex policies
• Handle complexity with composition
• Polymer language
• Summary

24
Enforcement Powers Related Work

• Previous work has examined the enforcement bounds
  of monitors Schneider 00 Viswanathan 00
  Hamlen, Morrisett, Schneider 03 Fong 04
• In the previous models, monitors respond to
  dangerous actions by halting the target outright
• Our framework considers more expressive monitors
  that can accept, suppress, and insert actions

25
Enforcing Properties with Edit Automata

• Powerful enforcement technique
• Suppress (feign execution of) potentially bad
  actions, and later, if the suppressed actions are
  found to be safe, re-insert them
• Limitation model assumes monitors have same
  computational power as observing system
• In practice, some actions cannot be feigned
• Actions requiring an outside system to execute
• Time-dependent actions

26
Renewal Property Definition

• Technique of suppressing dangerous actions allows
  edit automata to enforce any reasonable infinite
  renewal property
• Renewal Infinite executions are good iff they
  are good infinitely often

"sÎA? p(s) Û us p(u) is an infinite set
27
Example Renewal Property

• Check subsystem configuration after rebooting
• Whenever reboot is called, it must be followed
  by a call to checkConf
• Is a renewal property
• A valid infinite execution has infinitely many
  valid prefixes (in which checkConf always follows
  reboot)
• An invalid infinite execution has only finitely
  many valid prefixes
• There must be some invalid prefix where the next
  action after a reboot is not checkConf all
  successive prefixes are invalid

28
Edit Automata Enforcement(Lower Bound)

• Theorem " properties p such that 1. p is a
  renewal property, 2. p(?), and 3. "sÎA
  p(s) is decidable, an edit automaton that
  enforces p.

Edit automata can enforce any reasonable renewal
property
29
Edit Automata Enforcement(Lower Bound)

• Proof idea Technique of suppressing actions
  until they are known to be safe causes every
  valid prefix, and only valid prefixes, of the
  input to be output
• Given a renewal property p, construct an edit
  automaton X that uses this technique
• In all cases, X correctly enforces p
• If input s has finite length, X outputs longest
  valid prefix of s
• Else if Øp(s) and s is infinite, X outputs the
  longest valid (finite) prefix of s (since p is a
  renewal property)
• Else if p(s) and s is infinite, X outputs every
  prefix of s and only prefixes of s

30
Edit Automata Enforcement (Precise Bounds)

• An edit automaton can only enforce reasonable
  renewal properties, except for a corner case that
  allows some valid infinite-length executions to
  have only finitely many valid prefixes

31
Enforcing Almost Renewal Properties
Valid output
Untrusted input
a1a2a2a3
Monitor
Mr. Monitor Im examining action a1. a1 is
valid.
Valid output
Untrusted input
a1a2a2a3
a1
Monitor
32
Enforcing Almost Renewal Properties
Valid output
Untrusted input
a1a2a2a3
a1
Monitor
Mr. Monitor Im examining action a2. a1a2
is invalid, and the only valid extension of
a1a2 is a1a2a2a2 Ill just infinitely
insert a2.
Valid output
Untrusted input
a1a2a2a3
a1a2a2a2a2
Monitor
33
Edit Automata Enforcement (Precise Bounds)

• Enforcing an almost renewal property requires
  automaton having already input sequence s to be
  able to decide
• only one extension s of s is valid
• s has infinite length
• how to compute the actions in s

34
Safety, Liveness, Renewal

• Let us compare the set of renewal properties with
  the well-established sets of safety and liveness
  properties
• Safety Bad executions cannot be made good
• Liveness Finite executions can be made good
• Renewal Infinite executions are good iff they
  are good infinitely often

35
Example Renewal Property, Revisited

• Check subsystem configuration after rebooting
• Whenever reboot is called, it must be followed
  by a call to checkConf
• Is not a safety property Øp(reboot) but
  p(rebootcheckConf)
• Is not a liveness property
• reboota cannot be made good when a¹checkConf

36
Safety, Liveness, Renewal
All Properties
1 File access control 2 Trivial 3 Eventually
audits 4 Check configuration after
rebooting 5 Termination 6 Termination File
access control
Renewal
Safety
Liveness
1
2
3
5
4
6
37
Outline

• Motivation
• Which policies can monitors enforce?
• Language for writing complex policies?
• Delineating the enforceable policies
• Formally define monitor enforces a policy
• Analysis of enforcement powers
• A language for writing complex policies
• Handle complexity with composition
• Polymer language
• Summary

38
Managing Complexity via Centralization
Application with policyscattered throughout
Application with centralized policy
Policy contains - Security code - When to run
the security code
Scattered policy is hard to find and reason
about
Centralized policy is easier to find and reason
about
39
Beyond Centralization Composition

• Policy centralization is not enough
• Need methodology for organizing a complex
  centralized policy
• Our language Polymer provides a flexible
  methodology for decomposing complex policies into
  simpler modules
• Policies are first-class and organized for
  composition
• Higher-order policies (superpolicies) can compose
  simpler policies (subpolicies)

40
Outline

• Motivation
• Which policies can monitors enforce?
• Language for writing complex policies?
• Delineating the enforceable policies
• Formally define monitor enforces a policy
• Analysis of enforcement powers
• A language for writing complex policies
• Handle complexity with composition
• Polymer language
• Summary

41
Polymer Language Overview

• Syntactically almost identical to regular Java
  source
• Primary additions to Java
• Key abstractions for first-class actions,
  suggestions, and policies
• Programming discipline
• Composeable policy organization

42
First-class Actions

• Action objects contain information about a method
  invocation
• Static method signature
• Dynamic calling object
• Dynamic parameters
• Policies can analyze actions about to be executed
  by the target
• Policies can synthesize actions to invoke on
  behalf of the target

43
Action Patterns

• Action objects can be matched to patterns in
  aswitch statements
• Wildcards can appear in action patterns

aswitch(a) case ltvoid System.exit(int
status)gt E
ltpublic void java.io..ltinitgt(int i, )gt
44
First-class Suggestions

• Policies return Suggestion objects to indicate
  how to handle trigger actions
• IrrSug action is irrelevant
• OKSug action is relevant but safe
• InsSug defer judgment until after running and
  evaluating some auxiliary code
• ReplSug replace action (which computes a return
  value) with another return value
• ExnSug raise an exception to notify target that
  it is not allowed to execute this action
• HaltSug disallow action and halt execution

45
First-class Suggestions

• Suggestions implement the theoretical
  capabilities of monitors
• IrrSug
• OKSug
• InsSug
• ReplSug
• ExnSug
• HaltSug

Different ways to accept
Insert
Different ways to suppress
46
First-class Policies

• Policies include state and several methods
• query() suggests how to deal with trigger actions
• accept() performs bookkeeping before a suggestion
  is followed
• result() performs bookkeeping after an OKd or
  inserted action returns a result

public abstract class Policy public
abstract Sug query(Action a) public void
accept(Sug s) public void result(Sug s,
Object result, boolean wasExnThn)

47
Compositional Policy Design

• query() methods should be effect-free
• Superpolicies test reactions of subpolicies by
  calling their query() methods
• Superpolicies combine reactions in meaningful
  ways
• Policies cannot assume suggestions will be
  followed
• Effects postponed for accept() and result()

48
A Simple Policy That Forbids Runtime.exec(..)
methods
public class DisSysCalls extends Policy
public Sug query(Action a) aswitch(a)
case lt java.lang.Runtime.exec(..)gt
return new HaltSug(this, a)
return new IrrSug(this)
public void accept(Sug s)
if(s.isHalt()) System.err.println(Il
legal exec method called)
System.err.println(About to halt target.)

49
Another Examplepublic class rebootPolicy
extends Policy
public Suggestion query(Action a) aswitch(a)
case ltvoid ex.SubSys.reboot( )gt
if(needToCheck) return new HaltSug(
) else if(aboutToInsert)
return new OKSug( ) else
return new ReplSug(null) case lt
ex.SubSys.checkConf( )gt if(needToCheck)
return new InsSug(rebootAct(a))
else return new IrrSug( ) default
if(needToCheck) return new
HaltSug( ) else return new IrrSug( )

private boolean needToCheck false private
boolean aboutToInsert false public void
accept(Sug s) if(s.isReplace( ))
needToCheck true else if(s.isInsert( ))
needToCheck false aboutToInsert
true else if(s.isOK( ))
aboutToInsert false
50
Policy Combinators

• Polymer provides library of generic superpolicies
  (combinators)
• Policy writers are free to create new combinators
• Standard form

public class Conjunction extends Policy
private Policy p1, p2 public
Conjunction(Policy p1, Policy p2)
this.p1 p1 this.p2 p2 public
Sug query(Action a) Sug s1
p1.query(a), s2 p2.query(a) //return
the conjunction of s1 and s2
51
Policy Combinator I Conjunction

• Apply several policies at once, first making any
  insertions suggested by subpolicies
• When no subpolicy suggests an insertion, obey
  most restrictive subpolicy suggestion

Replace(v1)
Replace(v2)
Irrelevant
OK
Exception
Halt
Replace(v3)

Least restrictive
Most restrictive
52
Policy Combinator II Selector

• Make some initial choice about which subpolicy to
  enforce and forget about the other subpolicies
• IsClientSigned Enforce first subpolicy if and
  only if target is cryptographically signed

Policy sandboxUnsigned new IsClientSigned(
new TrivialPolicy(), new SandboxPolicy())
53
Policy Combinator III Precedence

• Give one subpolicy precedence over another
• Dominates Obey first subpolicy if it considers
  the action relevant otherwise obey whatever
  second subpolicy suggests
• TryWith Obey first subpolicy if and only if it
  returns an Irrelevant, OK, or Insertion
  suggestion

54
Policy Combinator IV Single-policy Modifier

• Perform some extra operations while enforcing a
  single subpolicy
• Audit Obey sole subpolicy but also log all
  actions seen and suggestions made
• AutoUpdate Obey sole subpolicy but also
  intermittently check for subpolicy updates

55
Case Study

• Polymer policy for email clients that use the
  JavaMail API
• Approx. 1800 lines of Polymer code, available
  athttp//www.cs.princeton.edu/sip/projects/polyme
  r
• Tested on Pooka http//www.suberic.net/pooka
• Approx. 50K lines of Java code libraries
• (Java standard libraries, JavaMail, JavaBeans
  Activation Framework, JavaHelp, The Knife mbox
  provider, Kunststoff Look and Feel, and ICE JNI
  library)

56
Email Policy Hierarchy

• Related policy concerns are modularized
• Easier to create the policy
• Modules are reusable
• Modules can be written in isolation
• Easier to understand the policy

57
Outline

• Motivation
• Which policies can monitors enforce?
• Language for writing complex policies?
• Delineating the enforceable policies
• Formally define monitor enforces a policy
• Analysis of enforcement powers
• A language for writing complex policies
• Handle complexity with composition
• Polymer language
• Summary

58
Summary

• Monitors modeled by edit automata can enforce
  reasonable renewal properties, including some
  non-safety properties
• A new approach to managing policy complexity
• Build complex policies can as compositions of
  simpler subpolicy modules
• Possible because policies are first-class and
  organized into effectless query methods and
  effectful bookkeeping methods

59
End