Jay Ligatti University of South Florida Slide 2 Interpose on the
actions of some untrusted software Have authority to decide whether
and how to allow those actions to be executed Are called
runtime/security/program monitors 2 untrusted software monitor
action-executing system (OS/hardware) possibly unsafe action a safe
action a a=open(file,r) | shutdown() | login(sn,pw) |
connect(addr,port) | Slide 3 Monitoring code can be inserted into
the untrusted software or the executing system 3 untrusted software
monitor executing system safe actions untrusted software executing
system possibly unsafe actions monitor Slide 4 In all cases monitor
inputs possibly unsafe actions from the untrusted software and
outputs safe actions to be executed 4 untrusted software monitor
action-executing system (OS/hardware) possibly unsafe action a safe
action a Slide 5 Ubiquitous Operating systems (e.g., file access
control) Virtual machines (e.g., stack inspection) Web browsers
(e.g., javascript sandboxing) Intrusion-detection systems Firewalls
Auditing tools Spam filters Etc. Most of what are usually
considered computer security mechanisms can be thought of as
runtime monitors 5 Slide 6 How do monitors operate to enforce
policies? Which policies can runtime mechanisms enforce? Which
policies should we never even try to enforce at runtime? All
policies Runtime-enforceable policies 6 Slide 7 How do monitors
operate to enforce policies? Which policies get enforced when we
combine runtime mechanisms? mechanism M enforces policy P mechanism
M enforces policy P M ^ M enforces? P ^ P ? What if P requires the
first action executed to be fopen( f ), but P requires the first
action executed to be fopen( f )? 7 Slide 8 How do monitors operate
to enforce policies? How efficiently does a mechanism enforce a
policy? What are the lower bounds on resources required to enforce
policies of interest? What does it mean for a mechanism to be
efficient? Low space usage (SHA of Fong, BHA of Talhi, Tawbi, and
Debbabi) Low time usage ? 8 Slide 9 How do monitors operate to
enforce policies? Which policies can runtime mechanisms enforce?
Which policies get enforced when we combine runtime mechanisms? How
efficiently does a mechanism enforce a policy? What are the lower
bounds on resources required to enforce policies of interest? 9
Slide 10 How do monitors operate to enforce policies? Which
policies can runtime mechanisms enforce? Which policies get
enforced when we combine runtime mechanisms? How efficiently does a
mechanism enforce a policy? What are the lower bounds on resources
required to enforce policies of interest? 10 Slide 11 Research
questions How do monitors operate to enforce policies? Which
policies can runtime mechanisms enforce? Related work vs. this work
The model: systems, executions, monitors, policies, and enforcement
Analysis of enforceable properties Summary and future work 11 Slide
12 Most analyses of monitors are based on truncation automata
(Schneider, 2000) Operation: halt software being monitored (target)
immediately before any policy violation Limitation: real monitors
normally respond to violations with remedial actions target monitor
executing system (OS/VM/CPU) possibly unsafe action a Halt target!
12 Slide 13 Powerful model of runtime enforcement Operation:
actively transform target actions to ensure they satisfy desired
policy target monitor executing system (OS/VM/CPU) possibly unsafe
action a a a'a' etc. (quietly suppress a) 13 Slide 14 Limitation:
All actions are assumed totally asynchronous Monitor can always get
next action after suppressing previous actions Target cant care
about results of executed actions; there are no results in the
model E.g., the echo program x=input(); output(x); is outside the
edit-automata model 14 Slide 15 Conservatively assume all actions
are synchronous and monitor those actions and their results
Operation: actively transform actions and results to ensure they
satisfy desired policy Untrusted Application safe results Executing
System (Trusted) Security Monitor actionssafe actions results 15
Slide 16 MRAs are stronger than truncation automata Can accept
actions and halt targets but can also transform actions and results
MRAs are weaker than edit automata Asynchronicity lets edit
automata see arbitrarily far into the future Can postpone deciding
how to edit an action until later Arbitrary postponement is
normally unrealistic 16 Slide 17 1. MRAs can enforce
result-sanitization policies (trusted) mechanism sanitizes results
before they get input to (untrusted) target application Many
privacy, information-flow, and access- control policies are
result-sanitization Untrusted Application Executing System
(Trusted) Security Monitor (1) ls (3) {foo.txt,.hidden} (2) ls (4)
{foo.txt} 17 Slide 18 2. Model provides simpler and more expressive
definitions of policies and enforcement than previous work (more on
this later) 18 Slide 19 Research questions How do monitors operate
to enforce policies? Which policies can runtime mechanisms enforce?
Related work vs. this work The model: systems, executions,
monitors, policies, and enforcement Analysis of enforceable
properties Summary and future work 19 Slide 20 Systems are
specified as sets of events Let A be a finite or countably infinite
set of actions Let R (disjoint from A) be a finite or countably
infinite set of action results Then a system is specified as E = A
R Example: A = {popupWindow(Confirm Shutdown), shutdown()} R = {OK,
cancel, null} 20 Slide 21 Execution: finite/infinite sequence of
events Adopting a monitor-centric view, 4 event possibilities: (1)
MRA inputs action a from the target Untrusted Application Executing
System (Trusted) Security Monitor a => add a i to the current
trace 21 Slide 22 Execution: finite/infinite sequence of events
Adopting a monitor-centric view, 4 event possibilities: (2) MRA
outputs action a to be executed Untrusted Application Executing
System (Trusted) Security Monitor a => add a o to the current
trace 22 Slide 23 Execution: finite/infinite sequence of events
Adopting a monitor-centric view, 4 event possibilities: (3) MRA
inputs result r from the system Untrusted Application Executing
System (Trusted) Security Monitor r => add r i to the current
trace 23 Slide 24 Execution: finite/infinite sequence of events
Adopting a monitor-centric view, 4 event possibilities: (4) MRA
outputs result r to the target Untrusted Application Executing
System (Trusted) Security Monitor => add r o to the current
trace r 24 Slide 25 ls i ; ls o ; {foo.txt,.hidden} i ; {foo.txt} o
Untrusted Application Executing System (Trusted) Security Monitor
ls 25 Slide 26 ls i ; ls o ; {foo.txt,.hidden} i ; {foo.txt} o
Untrusted Application Executing System (Trusted) Security Monitor
ls 26 Slide 27 ls i ; ls o ; {foo.txt,.hidden} i ; {foo.txt} o
Untrusted Application Executing System (Trusted) Security Monitor
{foo.txt,.hidden} 27 Slide 28 ls i ; ls o ; {foo.txt,.hidden} i ;
{foo.txt} o Untrusted Application Executing System (Trusted)
Security Monitor {foo.txt} 28 Slide 29 shutdown i ; popupConfirm o
; OK i ; shutdown o Untrusted Application Executing System
(Trusted) Security Monitor shutdown 29 Slide 30 shutdown i ;
popupConfirm o ; OK i ; shutdown o Untrusted Application Executing
System (Trusted) Security Monitor popupConfirm 30 Slide 31 shutdown
i ; popupConfirm o ; OK i ; shutdown o Untrusted Application
Executing System (Trusted) Security Monitor OK 31 Slide 32 shutdown
i ; popupConfirm o ; OK i ; shutdown o Untrusted Application
Executing System (Trusted) Security Monitor shutdown 32 Slide 33
getMail(server) i ; null o ; getMail(server) i ; null o ; Untrusted
Application Executing System (Trusted) Security Monitor
getMail(server) 33 Slide 34 getMail(server) i ; null o ;
getMail(server) i ; null o ; Untrusted Application Executing System
(Trusted) Security Monitor null 34 Slide 35 getMail(server) i ;
null o ; getMail(server) i ; null o ; 35 Etc This is an
infinite-length execution, so it represents a nonterminating run of
the monitor (and target application) Slide 36 E * = set of all
well-formed finite-length executions on system with event set E E =
set of all well-formed infinite-length executions on system with
event set E E = E * E = empty execution (no events occur) x;x =
well-formed concatenation of executions x and x x x = execution x
is a prefix of x 36 Slide 37 Metavariable ____ ranges over ____ e
over events a over actions r over results x over executions over A
{ } (potential actions) over R { } (potential results) 37 Slide 38
An MRA M is a tuple (E, Q, q 0, ) E = event set over which M
operates Q = Ms finite or countably infinite state set q 0 = Ms
initial state = Ms (partially recursive) transition function : Q x
E Q x E given a current MRA state and an event just input, returns
the next MRA state and an event to output 38 Slide 39 q is the MRAs
current state i is empty or the action being input to the MRA o is
empty or the action being output from the MRA i is empty or the
result being input to the MRA o is empty or the result being output
from the MRA 39 ii oo q oo ii Untrusted Application Executing
System (Trusted) Security Monitor ii oo ii oo q Slide 40 Starting
configuration: A single-step judgment specifies how MRAs take small
steps (to input/output a single event) Single-step judgment form: C
C Then the multi-step judgment is the reflexive, transitive closure
of the single-step relation Multi-step judgment form: C * C 40 q0q0
e x Slide 41 Rules for inputting and reacting to actions: 41 next T
= a q aiai q a (q,a) = (q,a) q a a o q a (q,a) = (q,r) q a roro q r
(Output-Action-for-Action) (Output-Result-for-Action)
(Input-Action) Slide 42 Rules for inputting and reacting to
results: 42 next S = r q a riri q r (q,r) = (q,a) q r aoao q a
(q,r) = (q,r) r o q r q r (Input-Result) (Output-Action-for-Result)
(Output-Result-for-Result) Slide 43 M x means MRA M, when its input
events match the (possibly infinite) sequence of input events in x,
produces the execution x M x iff: if x E then xx : C : C 0 * C if x
E * then C : C 0 * C if x ends with an input event then M never
transitions from C 43 x x Slide 44 Semantics matches the possible
behaviors weve observed in many implemented monitoring systems
Polymer (with Bauer and Walker) PSLang (Erlingsson and Schneider)
AspectJ (Kiczales et al.) Etc. 44 Slide 45 Hidden-file filtering
MRA M = (E, Q, q 0, ) E = { ls, } Q = { T, F } (are we executing an
ls?) q 0 = { F } ( F, e ) if q=F and els (q,e) = ( T, e ) if q=F
and e=ls ( F, filter(e)) if q=T 45 Slide 46 Shutdown-confirming MRA
M=(E, Q, q 0, ) E = { shutdown, popupConfirm, OK, cancel, null, } Q
= { T, F } (are we confirming a shutdown?) q 0 = { F } ( F, e ) if
q=F and eshutdown (q,e) = ( T, popupConfirm ) if q=F and e=shutdown
( F, null ) if q=T and e=cancel ( F, shutdown ) if q=T and e=OK 46
Slide 47 (Technical note: here were really only considering special
kinds of policies called properties) Policies are predicates on (or
sets of) executions P(x) iff execution x satisfies policy P 47
Slide 48 P( ) P(ls i ) P(ls i ; e o ) iff e=ls results L: P(ls i ;
ls o ; L i ) P(ls i ; ls o ; L i ; e o ) iff e=filter(L) [its OK
for the target to do nothing] [monitor may not just stop upon
inputting ls; must then output ls] [monitor must output only ls
after inputting ls; its then OK for the system to never return a
listing] [monitor may not stop upon inputting L; must return the
filtered list to the target] [monitor must filter listings] 48
Slide 49 Policies here can reason about results Enables
result-sanitization policies E.g., filter-hidden-file policy
Policies here can reason about input events Enables policies to
dictate exactly how mechanisms can/must transform events E.g.,
confirm-shutdown policy => Powerful, but practical,
expressiveness 49 Slide 50 Sound enforcement (no false -s) Complete
enforcement (no false +s) Precise enforcement (no false +s or -s)
MRA M soundly enforces policy P iff x E : (M x P(x)) MRA M
completely enforces policy P iff x E : (P(x) M x) MRA M precisely
enforces policy P iff x E : (M x P(x)) 50 Slide 51 Simpler: no need
for extra transparency constraints that can be rolled into policy
definitions (now that policies can reason about input events) More
expressive: can reason about complete and precise enforcement too
51 Slide 52 Research questions How do monitors operate to enforce
policies? Which policies can runtime mechanisms enforce? Related
work vs. this work The model: systems, executions, monitors,
policies, and enforcement Analysis of enforceable properties What
are the limits of MRA enforcement? Summary and future work 52 Slide
53 Policy P on system with event set E can be soundly enforced by
some MRA M iff there exists (R.E.) predicate R over E * s.t. all
the following are true. R( ) (x;e i ) E * : R(x) or P(x;e i ) or e
E:(R(x;e i ;e o ) P(x;e i ;e o )) x E : if P(x) then (x;e i )x:R(x)
53 Slide 54 Policy P on system with event set E can be completely
enforced by some MRA M iff: (x;e i ) E * : e E : dead P (x;e i ;e o
) or P(x;e i ) !e E : alive P (x;e i ;e o ) (where alive P (x) iff
x E :P(x;x) and dead P (x) iff alive P (x) ) 54 Slide 55 Policy P
on system with event set E can be precisely enforced by some MRA M
iff all the following are true. P( ) (x;e i ) E * : P(x) or P(x;e i
) e E : dead P (x;e i ;e o ) or P(x;e i ) !e E : P(x;e i ;e o ) !e
E : alive P (x;e i ;e o ) x E : if P(x) then (x;e i )x:P(x) 55
Slide 56 Research questions How do monitors operate to enforce
policies? Which policies can runtime mechanisms enforce? Related
work vs. this work The model: systems, executions, monitors,
policies, and enforcement Analysis of enforceable properties
Summary and future work 56 Slide 57 Started building a theory of
runtime enforcement based on MRAs, which: model the realistic
ability of runtime mechanisms to transform synchronous actions and
their results. can enforce result-sanitization policies and
policies based on input events. provide simpler and more expressive
definitions of policies and enforcement than previous models. 57
Slide 58 Something between edit automata (which assume asynchronous
actions) and MRAs (which assume synchronous actions)? How would the
monitor know when the target is waiting for a result, and for which
action? Static analysis of target application? Could get
complicated 58 Slide 59 Which policies get enforced when we combine
runtime mechanisms? How efficiently does a mechanism enforce a
policy? What are the lower bounds on resources required to enforce
policies of interest? Having a realistic operational model of
runtime enforcement seems like a good first step to address these
research questions 59 Slide 60 60
