Jay Ligatti University of South Florida Runtime Enforcement Mechanisms for Software Interpose on the actions of some untrusted software Have authority to decide whether and how to allow those actions to be executed ID: 593415
Download Presentation The PPT/PDF document "Modeling Enforcement Mechanisms with Sec..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Modeling Enforcement Mechanisms with Security Automata
Jay
Ligatti
University of South FloridaSlide2
Runtime Enforcement Mechanisms, for Software
Interpose on the actions of some
untrusted
softwareHave authority to decide whether and how to allow those actions to be executedAre called runtime/security/program monitors
2
untrustedsoftware
monitor
action-executing
system
(OS/hardware)
possibly
unsafe
action a
safe
action a
a=open(
file,“r
”) | shutdown() | login(
sn,pw
) | connect(
addr,port
) |…Slide3
Runtime Enforcement Mechansisms
Monitoring code can be inserted into the
untrusted
software or the executing system
3
untrustedsoftware
monitor
executing
system
safe actions
untrusted
software
executing system
possibly
unsafe
actions
monitorSlide4
Runtime Enforcement Mechanisms
In all cases
monitor inputs possibly unsafe actions
from the untrusted software and outputs safe actions to be executed
4
untrustedsoftware
monitor
action-executing
system
(OS/hardware)
possibly
unsafe
action a
safe
action aSlide5
Runtime Enforcement Mechanisms
Ubiquitous
Operating systems (e.g., file access control)
Virtual machines (e.g., stack inspection)Web browsers (e.g., javascript sandboxing)Intrusion-detection systemsFirewallsAuditing tools
Spam filtersEtc.Most of what are usually considered “computer security” mechanisms can be thought of as runtime monitors
5Slide6
Research Questions
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
6Slide7
Research Questions
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’ )?
7Slide8
Research Questions
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?
8Slide9
Research Questions, Summary
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?
9Slide10
This Talk
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?
10Slide11
Outline
Research questions
How do monitors operate to enforce policies?
Which policies can runtime mechanisms enforce?Related work vs. this workThe model: systems, executions, monitors, policies, and enforcementAnalysis of enforceable propertiesSummary and future work
11Slide12
Related Work: Truncation Automata
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
action a
Halt target!
12Slide13
Related Work: Edit Automata
P
owerful 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
'
etc.
(quietly
suppress
a)
13Slide14
Related Work: Edit Automata
Limitation
:
All actions are assumed totally asynchronousMonitor can always get next action after suppressing previous actionsTarget can’t care about results
of executed actions; there are no results
in the modelE.g., the echo program “x=input(); output(x);” is outside the edit-automata model
14Slide15
This Work: Mandatory Results Automata (MRAs)
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
UntrustedApplication
safe
results
Executing
System
(Trusted)
Security
Monitor
actions
safe
actions
results
15Slide16
MRAs are
stronger than truncation automata
Can accept actions and halt targets but can also
transform actions and resultsMRAs are weaker than edit automataAsynchronicity lets edit automata “see” arbitrarily far into the futureCan postpone deciding how to edit an action until later
Arbitrary postponement is normally unrealistic
16
This Work: Mandatory Results Automata (MRAs)Slide17
Other Neat Features of the MRA Model
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}
17Slide18
Other Neat Features of the MRA Model
Model provides
simpler
and more expressive definitions of policies and enforcement than previous work
(more on this later)
18Slide19
Outline
Research questions
How do monitors operate to enforce policies?
Which policies can runtime mechanisms enforce?Related work vs. this workThe model: systems, executions, monitors, policies, and enforcementAnalysis of enforceable propertiesSummary and future work
19Slide20
Systems
Systems are specified as sets of
events
Let A be a finite or countably infinite set of actionsLet R (disjoint from A) be a finite or countably
infinite set of action resultsThen a
system is specified as E = A ∪ RExample: A = {popupWindow(“Confirm Shutdown”), shutdown()}
R = {OK, cancel, null}20Slide21
Definition of MRA traces/executions
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
21Slide22
Definition of MRA traces/executions
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
22Slide23
Definition of MRA traces/executions
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
23Slide24
Definition of MRA traces/executions
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
24Slide25
Example Execution
ls
i
; lso ; {foo.txt, .hidden}i
; {foo.txt}o
Untrusted
Application
Executing
System
(Trusted)
Security
Monitor
ls
25Slide26
Example Execution
ls
i
; lso ; {foo.txt, .hidden}i
; {foo.txt}o
Untrusted
Application
Executing
System
(Trusted)
Security
Monitor
ls
26Slide27
Example Execution
ls
i
; lso ; {foo.txt, .hidden}i
; {foo.txt}o
Untrusted
Application
Executing
System
(Trusted)
Security
Monitor
{foo.txt, .hidden}
27Slide28
Example Execution
ls
i
; lso ; {foo.txt, .hidden}i ; {foo.txt}
o
Untrusted
Application
Executing
System
(Trusted)
Security
Monitor
{foo.txt}
28Slide29
Another Example Execution
shutdown
i
; popupConfirmo ; OK
i ; shutdowno
Untrusted
Application
Executing
System
(Trusted)
Security
Monitor
shutdown
29Slide30
Another Example Execution
shutdown
i
; popupConfirmo ; OK
i ; shutdowno
Untrusted
Application
Executing
System
(Trusted)
Security
Monitor
popupConfirm
30Slide31
Another Example Execution
shutdown
i
; popupConfirmo ; OKi
; shutdowno
Untrusted
Application
Executing
System
(Trusted)
Security
Monitor
OK
31Slide32
Another Example Execution
shutdown
i
; popupConfirmo ; OKi ;
shutdowno
Untrusted
Application
Executing
System
(Trusted)
Security
Monitor
shutdown
32Slide33
Last Example Execution
getMail
(server)
i ; nullo
; getMail(server)i
; nullo ; …
Untrusted
Application
Executing
System
(Trusted)
Security
Monitor
getMail
(server)
33Slide34
Last Example Execution
getMail
(server)
i ; nullo ;
getMail(server)i
; nullo ; …
UntrustedApplication
Executing
System
(Trusted)
Security
Monitor
null
34Slide35
Last Example Execution
getMail
(server)
i ; nullo ;
getMail(server)i
; nullo
; …35
Etc… This is an infinite-length execution, so it represents a nonterminating run
of the monitor (and target application)Slide36
Notation
E
*
= set of all well-formed finite-length executions on system with event set EEω = set of all well-formed
infinite-length executions on system with event set EE
∞ = 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’
36Slide37
More Notation
Metavariable
____
ranges over ____e over eventsa over actionsr over results
x over executionsα
over A ∪ { } (potential actions)ρ over R ∪ { } (potential results)
37Slide38
Definition of MRAs
An MRA M is a tuple (E, Q, q
0
, δ)E = event set over which M operates
Q = M’s finite or countably
infinite state setq0 = M’s initial state
δ = M’s (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
38Slide39
MRA Configurations
q is the MRA’s 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
α
i
αoq
ρ
o
ρi
UntrustedApplication
Executing
System
(Trusted)
Security
Monitor
α
i
α
o
ρ
i
ρ
o
qSlide40
MRA Operational Semantics
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 relationMulti-step judgment form: C →
* C’40
q
0
e
xSlide41
Single-step Rules
Rules for inputting and reacting to
actions
:41
→
nextT = a
q
ρ
a
i
q
a
→
δ
(
q,a
) = (
q’,a
’)
q
a
a’
o
q’
a’
→
δ
(
q,a
) = (
q’,r
)
q
a
r
o
q’
r
(Output-Action-for-Action)
(Output-Result-for-Action)
(Input-Action)Slide42
Single-step Rules
Rules for inputting and reacting to
results
:42
→
nextS = r
q
a
r
i
q
r
→
δ
(
q,r
) = (
q’,a
)
q
r
a
o
q’
a
→
δ
(
q,r
) = (
q’,r
’)
r’
o
q’
r’
q
r
(Input-Result)
(Output-Action-for-Result)
(Output-Result-for-Result)Slide43
One More Operational Judgment
M
x means MRA M, when its input events match the (possibly infinite) sequence of input events in x, produces
the execution xM
x iff:if x∈Eω then ∀
x’≤x : ∃C : C0 →* Cif
x∈E* then ∃C : C0 →
* Cif x ends with an input event then M never transitions from C
43x’
xSlide44
Observation
Semantics matches the possible behaviors we’ve observed in many implemented monitoring systems
Polymer (with Bauer and Walker)
PSLang (Erlingsson and Schneider)AspectJ (Kiczales
et al.)Etc.
44Slide45
Example MRA
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 e<>
lsδ(q,e) = ( T , e ) if q=F and e=
ls ( F , filter(e)) if q=T
45Slide46
Another Example MRA
Shutdown-confirming MRA M=
(
E, Q, q0, δ)
E = { shutdown, popupConfirm
, OK, cancel, null, …}Q = { T , F } (are we confirming a shutdown?)
q0 = { F }
( F , e ) if q=F and e<>shutdownδ(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
46Slide47
Definition of Policies
(Technical note: here we’re really only considering special kinds of policies called
properties
)Policies are predicates on (or sets of) executionsP(x) iff execution x satisfies policy P
47Slide48
Example: Definition of the
Filter-hidden-files Policy
P( )
¬
P(ls
i)
P(lsi ;
eo) iff e=
ls
∀ results L: ¬ P(
lsi ; ls
o ; L
i)
P(lsi ;
lso ; L
i
;
e
o
)
iff
e=filter(L)
[it’s 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
; it’s 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]
48Slide49
How Policies in MRA Model Differ from Those of Previous Models
Policies here can reason about
results
Enables result-sanitization policiesE.g., filter-hidden-file policyPolicies here can reason about input
eventsEnables policies to dictate exactly how mechanisms
can/must transform eventsE.g., confirm-shutdown policy=> Powerful, but practical, expressiveness
49Slide50
Definitions of Enforcement
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) ⇒ Mx
)MRA M precisely enforces policy P
iff ∀x∈E∞: (
Mx ⇔ P(x))
50Slide51
How Enforcement in MRA Model
Differs
from
That of Previous ModelsSimpler: 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 too51Slide52
Outline
Research questions
How do monitors operate to enforce policies?
Which policies can runtime mechanisms enforce?Related work vs. this workThe model: systems, executions, monitors, policies, and enforcementAnalysis of enforceable propertiesWhat are the limits of MRA enforcement?
Summary and future work
52Slide53
Sound Enforcement with MRAs
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) orP(x;ei) or∃e’∈E
:(R(x;ei;e’o) ∧ P(x;e
i;e’o)) ∀x∈Eω
: if ¬P(x) then ∃(x’;ei)≤x:¬R(x’)
53Slide54
Complete Enforcement with MRAs
Policy P on system with event set E can be completely enforced by some MRA M
iff
:∀(x;ei)∈E* : ∀
e’∈E : deadP
(x;ei;e’o) or¬P(
x;ei) ∧ ∃!e’∈E : aliveP(
x;ei;e’o)
(where aliveP(x) iff ∃
x’∈E∞:P(x;x’) and dead
P(x) iff ¬aliveP(x) )
54Slide55
Precise Enforcement with MRAs
Policy P on system with event set E can be precisely enforced by some MRA M
iff
all the following are true.P( )∀(x;ei)∈E*
: ¬P(x) orP(x;e
i) ∧ ∀e’∈E : deadP(x;e
i;e’o) or¬P(x;ei
) ∧ ∃!e’∈E : P(x;ei;e’o) ∧ ∃!
e’∈E : aliveP(
x;ei;e’o)∀x∈E
ω : if ¬P(x) then ∃(x’;ei)≤x:¬P(x’)
55Slide56
Outline
Research questions
How do monitors operate to enforce policies?
Which policies can runtime mechanisms enforce?Related work vs. this workThe model: systems, executions, monitors, policies, and enforcementAnalysis of enforceable propertiesSummary and future work
56Slide57
Summary
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.
57Slide58
Future Work
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
58Slide59
Additional Future Work
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
59Slide60
Thanks/Questions?
60