Securing applications. Performance of Rotor CAS protection and capabilities

1. Securing applications.Performance of Rotor CAS protection and capabilities Darío Álvarez Gutiérrez,M. Ángeles Díaz Fondón, Iván Suárez Rodríguez darioa@uniovi.es Department of InformaticsUniversity of Oviedo, Asturias, Spain

2. Context • Project to build an operating system based on an OO Abstract Machine (“managed code”). • Own OO AM with object model • RISC-like, not a-la-java (no stack, f.i.) • Search for access control mechanism (protection) • To control whether a “client” object can call a method of a “server object” (Eg: an “student” object can call the “change” method of a “grade” object). • Found (pure) capabilities are best for this environment (applied own variant) • => Protection should be part of the object model • RFPv1: Implementation into Rotor (RotorCapa)

3. Protection Mechanism(Access Control) • Access Control Mechanism (protection) • To control whether a piece of code (“subject”) can access a resource (“server” or “resource”). • Example: Access Control Lists • Access Control Mechanism in an OO environment • To control whether a “client” object can call a method of a “server object” • Eg: an “student” object can call the “change” method of a “grade” object.

4. Access Control inOO Abstract Machines • Examples of Access Control in OO environments based on OO Abstract Machines • Access Control Lists • .NET Code Access Security • Based on a form of stack introspection (stack walking) • Other access control mechanisms:(pure) CAPABILITIES • Our Focus: Application of capabilities to OO Abstract Machines • To our own OO Abstract Machine (Carbayonia) • Integration of capability-based protection in the SSCLI-Rotor

5. Pure Capabilities • What is a capability (pure or object capability) • A reference to an object together with a set of permissions on the methods of that object Holding a capability with the specific permission asserted is necessary and sufficient to access the method

6. Applying capabilities toOO Abstract Machines • Integrate protection into the object model (make protection a property of the object model) • Protection information (permissions) is integrated with the references • The control mechanism is integrated with the method call mechanism • Modifications to instructions (and structures) related to references must be done • Just a new instruction to restrict permissions in a reference (principle of least privilege) is needed

7. Applying capabilities toOO Abstract Machines (2) • Advantages • Naming and protection are combined • Flexibility and adaptability • High performance • permission checks take “constant” time • Integration with the object model (conceptual simplicity) • Fine granularity of protection • At the level of individual methods and object instances • Reduced Trusted Computing Base • A simple mechanism is implemented with a small code.

8. Applying capabilities toOO Abstract Machines (3) • Advantages (2) • More hardened systems • The principle of least privilege can be followed with no restrictions • “restrict” instruction at the level of single methods for specific references of objects. • Compatibility with existing applications • Capabilities are stored and used in objects as normal references in applications. • Scalability • Managing capabilities for thousands of objects is not a problem, as each object manages and stores its own capabilities (as normal references)

9. Applying capabilities toOO Abstract Machines (4) • Drawbacks • Control of propagation • sol.: Reference monitor • Revocation of permissions • sol.: Facades

10. Why Capabilities for .NET? • Capabilities have its own merits • Clearly superior to ACLs, for example • .NET can be used just as a platform to research on other protection mechanisms • .NET CAS is good and comprehensive, but there are problems sometimes (why capabilities?) • Complexity (evidence, policies, permission sets...) • Too much for many applications • Footprint and overhead, although just a small fraction is used • Big Trusted Computing Base

11. Why Capabilities for .NET? (2) • Access to source code of “server” needed • To add protection to a class, a “demand permissions” sentence, and the code to create permissions must be included • With capabilities any binary object can be protected anytime (just setting permissions in the references) • Protection at the level of the class, not at the level of individual instances • Permissions are assigned based (roughly speaking) on the class of a client instance, not on an instance-by-instance basis • With capabilities, permissions are assigned on a reference-by-reference basis • Two objects of the same class can hold different permissions when calling a third object.

12. Implanting Capabilities into Rotor: Overview • Add data to represent permissions in references • Modify instructions accordingly • Method calls (check permission is asserted in the reference) • Copying and passing references (copying permissions) • Add instruction to restrict permissions in a reference

13. Implanting Capabilities into Rotor: Alternative 1: Extend references • Extend the structure representing machine references (OBJECTREF) • Internally, a pointer to the memory representing the object • Add protection information here, and complement • But • Pointers are directly used in many places (JIT) • Alternative not possible

14. Implanting Capabilities into Rotor: Alt- 2: Permissions object (1) • Create a (managed) object to store the permissions • Modify the system to use this object with the references • When creating an object, create associated permissions objects for the references also • When passing a reference, pass the permissions object also • Modify references-related code to take into account the associated permissions objects.

15. Implanting Capabilities into Rotor: Alt. 2: Permissions object (2) • Examples of modifications needed • JIT Helpers • Library functions with native implementation • But • Almost a thousand native functions • What if one of these is forgotten? • Alternative not selected

16. Implanting Capabilities into Rotor: Alt. Selected: Objects as containers • Permissions for references in objects (members) • Use object structure as a container for permissions • Permissions for references in activation records (local variables and arguments)Permissions for references in evaluation stack • Use thread structure as a container for permissions • Modify instructions accordingly • Add “restrict” instruction

17. Representingpermissionsfor referencesin objects • Add a field to thestructure representingan object • Pointer to an structureholding the permissionsassociated to eachreference in the object(“CapabilitiesTable”). • Lazy-creation

18. Permissions for references in execution and evaluation stacks • Representing permissions for local variables and argument references (references in a stack frame) • Tables similar to those for references in objects • A stack with permissions for the references in stack frames grows in parallel with the execution stack • Representing permissions for references stacked in the evaluation stack • A stack with permissions for each stacked reference grows in parallel with the evaluation stack • Thread object is used as a container for these structures

19. Permissions forreferences inexecution andevaluationstacks

20. Changes to instructions (1) • New instruction “restrict <method>” • Acts upon reference in top of stack • Denies access to the given method • Primitive security operation • Secure computation in a capabilities system using “restrict” • The reference creating an object returns all permissions set (“owner”) • Reference is duplicated • Reference is restricted • Reference is passed to other objects in a method call for secure computation

21. Changes to instructions (2) • “call” and “callvirt” now check permissions • To make secure computation possible • Method calls check the permissions in the reference used to make the call (reference in the top of the stack) • An exception is raised if the permission for the method is not asserted in the reference • This is the only instruction with different semantics than before (now an exception might be thrown) • And this only if permissions are restricted

22. Changes to instructions (3) • Modifications to (many) other instructions • Other instructions that deal with references must take into account the associated permissions (copying, deleting, etc.): • Creation of new objects: newobj • The reference returned has an associated set of permissions, initially set to “1” for the creator). • Storing from the stack: starg, stlocs, stfld, stsfld • When storing a reference, the associated permissions must also be copied to the destination reference • Loading: ldarg, ldloc, ldnull, ldelem.x, ldelem.ref, ldfld, ldsfld, ldsflda, ldstr • symmetrically, permissions associated to a reference must be copied when the reference is pushed in the evaluation stack • Various: dup, isinst, box, unbox

23. Sample CLI code with “restrict” • ... • // An object is created and a reference// (capability) is left on the stack • newobj instance void Test::.ctor() • // A method is restricted in the capability// in the top of the stack • restrict instance void Test::Message() • // Now the method is invoked using the// reference in the top of the stack • // The reference can be stored, cloned,// passed as an argument to other objects, etc. • callvirt instance void Test::Message() • // The call will not succeed and an exception// is raised at this point, as the reference used// has not the permission to call “Message” set • ...

24. Cost of securing applications using capability-based protection • Early perfomance results encouraging • Next project: Thorough performance tests. Planned goals: • Improve implementation of RotorCapa VM • Develop “synthetic” benchmarks • Evaluate performance of Rotor and .NET CAS protection with “default” permissions (phase1) and with “custom” permissions (phase2) to compare with capabilities • Varying the number of domains, stack depth, etc. • Instrument “real” user applications (delayed) • How protection is used in “real life” and its cost

25. Improving the implementation of RotorCapa • RotorCapa adds capabilities for objects • Make it work with all Rotor elements (structs, byref pointers, etc.) • Wrong decision, in retrospect. Big delay, and it was not really important for the goal of the project • Slow, error-prone, difficult to debug • Our design has to “shadow” references with the corresponding permissions • References are really deep into Rotor, and we have to touch this • Every time and place a reference is moved, copied, etc., we have to do the same for the corresponding permission • This is done in many places inside Rotor, unmanaged code • Not 100% complete. Put to standby. • Delayed the project. Besides, chasing subtle bug introduced (may have to resort to previous version)

26. “Synthetic” benchmarks for protection • Benchmarks to exercise the machines with different • Domains • Stack sizes • Method complexities • Classes, methods and protected methods, etc. • Cost of checking permissions for a method with different configurations • Insight on parameters affecting performance of protection in Rotor • and .NET

27. “Synthetic” benchmarks for protection (3) • Design used: program generator • Input: Value of parameters (number of domains, stack size, classes, etc.) • Output: Benchmark program with that configuration • Benchmark program • Builds desired configuration (creates domains, instances, builds stack, etc.) • Repeatedly calls a method protected by a permission • Outputs time taken to do the calls (i.e: execution time for the method – i.e. cost of protecting the method)

28. “Synthetic” benchmarks for protection (4) • Phases • “Default” configuration – Rotor (.NET) • Built-in, default permissions for Application Domains • “Complex” configuration – Rotor (.NET) • Custom (“user” permissions) • Different permissions for Application Domains • (data not yet available)

29. “Synthetic” benchmarks for protection (5) • Phase 1. First batch • 1.800 runs approx. for configurations • Rotor, .NET (1.0) • Security enabled / disabled • Fulltrust / Specific permissions set • 1-5 Application Domains • Different numbers of classes, methods, instances, etc.

30. The cost of “default” protection (1) • Overall preliminary analysis – phase 1 • .NET is also very fast regarding CAS protection  • Times almost not measurable (same configuration as Rotor for reasonable run times of benchmarks) • Number of instances not relevant (expected) • Number of methods not relevant (expected) • Fulltrust slightly quicker than specific permission sets (expected) • Small tendency to increase times with stack size (clear in Rotor – about 4% difference from 1 domain to 5 domains with x5 stack size also)

31. The cost of “default” protection (2) • Number of domains not relevant – with same stack size • However, not totally representative as default policy gives all domains the same permissions

32. The cost of “default” protection (3) • Details on a specific batch run with varying stack sizes and method complexity • Security disabled faster than checking (expected) • Checking permissions slows with stack size • .NET much faster than Rotor (expected ), but behaviour similar • Mean overhead between 70% (Rotor) and 210% (.NET)

33. The cost of “default” protection (3) • Strange “pikes” for Rotor at given stack sizes • Mean overhead negligible (even-0.3%) • Mean overhead about 40%, but less as stack size is smaller • Absolute overhead, however, very small

34. The cost of “default” protection (3) • Analogous behaviour • Strange “pikes” for Rotor at given stack sizes • Mean overhead neglible (0,059%) • Analogous behaviour • Mean overhead (8%) • Absolute overhead, however, very small

35. Conclusions phase 1 “default” protection • Overhead of protection is very small in absolute terms • For “user” methods with modest complexity (just 100 times the complexity of a “null” call in the case of Rotor), it is in fact negligible) • All “user” calls could be protected by default if this holds

36. More benchmarks • Benchmarks phase 2 • Being finished • Thousands still to run (more being generated also for phase 1) • Application domains with custom permissions and permission sets (will the behaviour be similar for this) (and comparison with RotorCapa) • Complete results expected soon

37. Securing applications.Performance of Rotor CAS protection and capabilitieshttp://www.di.uniovi.es/~darioa/rotorcapa/ Darío Álvarez Gutiérrez,M. Ángeles Díaz Fondón, Iván Suárez Rodríguez darioa@uniovi.es Department of InformaticsUniversity of Oviedo, Asturias, Spain