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