KATHOLIEKEUNIVERSITEITLEUVEN
1
Run time enforcement of security policies on the .NET framework
Frank Piessens
Joint work with many people including Lieven Desmet, Pieter Philippaerts,Dries Vanoverberghe, Fabio Massacci, Katsiaryna Naliuka, Wouter Joosen
KATHOLIEKEUNIVERSITEITLEUVEN
Overview
• Problem statement• Policies• Enforcement• Our implementation for .NET• Conclusion
2
KATHOLIEKEUNIVERSITEITLEUVEN
Problem Statement
• How can you run an application and be sure it will not “do any harm”?
• Existing technologies for running applications under tight control of a security policy fall short:– On desktops/servers: no support for “quota” on
resources such as network bandwidth, windows,…– On smartphones / PDA’s: even no support for
configurable sandboxing
3
KATHOLIEKEUNIVERSITEITLEUVEN
Objective
• Efficiently enforce flexible security policies on applications running on the .NET framework– Both the full framework and the compact framework– Without modifications to the virtual machine or the
system libraries• Flexible policies means:
– Stateful (e.g. resource quota)– History based (e.g. privacy policies)– Context based (e.g. “only on business hours”)
4
KATHOLIEKEUNIVERSITEITLEUVEN
Policies
• Policies are specified as security automata– Security relevant events of an application are
transitions from the application into the platform libraries
– Application basically generates traces of such events– Policy is an automaton that specifies the set of
acceptable traces, possibly using context info• Example automaton:
– “no send after read”
5
KATHOLIEKEUNIVERSITEITLEUVEN
The CONSPEC policy language
6
SCOPE Session SECURITY STATE int activeConnections = 0; int maxConnections = 2;
BEFORE System.Net.Sockets.Socket.Connect(System.Net.EndPoint) PERFORM activeConnections < maxConnections -> { }
AFTER System.Net.Sockets.Socket.Connect(System.Net.EndPoint) PERFORM true -> { activeConnections++; }
(Designed in the European project S3MS)
KATHOLIEKEUNIVERSITEITLEUVEN
Enforcement of policies
• Inline reference monitor:– Rewrite an application to insert additional security
checks, in such a way that:– The rewritten application is guaranteed not to violate
the policy• Existing (research) systems (for Java):
– PoET/PSLang– Polymer– …
7
KATHOLIEKEUNIVERSITEITLEUVEN
Architecture of our system
8
Application
Execution Monitor
Sensitive Operations
1. E
vent
4. a
Eve
nt
8.a
Res
ult
5. R
esul
t
Policy Decision Point
2. Before_Event
3. Decision
6. After_Event
7. Decision
4.b
Term
inat
e
8.b
Term
inat
e Policy State Service
System Information
Service
Policy State
Secure Storage ServicePolicy State
Policy State
Policy State
System State
KATHOLIEKEUNIVERSITEITLEUVEN
Implementation
• Source policies are compiled to Policy Decision Points (PDP) assemblies
• Applications are rewritten to insert calls to the PDP assembly at each security relevant event
• The PDP either returns silently or throws a security exception
• Design and implementation: Pieter Philippaerts, Lieven Desmet and Dries Vanoverberghe
9
KATHOLIEKEUNIVERSITEITLEUVEN
10
Application DLL Rewriting at load time
MonitoredApplication DLL
Policy DLLSecurity events
.NET Common Language Runtime
KATHOLIEKEUNIVERSITEITLEUVEN
Status of the prototype
• This is ongoing research in the context of Sobenet and the European project Security of Software and Services for Mobile Systems (S3MS)
• Both a smartphone based system and a desktop based system is operational– With some limitations
• A visualization of policy state was implemented as part of Johan Moons’ master thesis
11
KATHOLIEKEUNIVERSITEITLEUVEN
12
KATHOLIEKEUNIVERSITEITLEUVEN
13
KATHOLIEKEUNIVERSITEITLEUVEN
14
KATHOLIEKEUNIVERSITEITLEUVEN
Conclusion
• Security automata are a powerful foundation for access control– Proven to be “complete” in some sense: anything
you can enforce can be specified as a security automaton
• Inline reference monitors are feasible on real-life applications
15