Run time enforcement of security policies on the .NET framework

1. Run time enforcement of security policies on the .NET framework Frank Piessens Joint work with many people including LievenDesmet, Pieter Philippaerts, Dries Vanoverberghe, Fabio Massacci, KatsiarynaNaliuka, WouterJoosen

2. Overview • Problem statement • Policies • Enforcement • Our implementation for .NET • Conclusion

3. 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

4. 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”)

5. 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”

6. The CONSPEC policy language (Designed in the European project S3MS) SCOPE Session SECURITY STATE intactiveConnections = 0; intmaxConnections = 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++; }

7. 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 • …

8. Architecture of our system

9. 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, LievenDesmet and Dries Vanoverberghe

10. Policy DLL Application DLL Monitored Application DLL Rewriting at load time Security events .NET Common Language Runtime

11. 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

15. 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