An Approach to Safe Object Sharing

1. An Approach to Safe Object Sharing Ciaran Bryce & Chrislain Razafimahefa University of Geneva, Switzerland

2. Goal • Need to isolate mistrusting programs from one another and protect host platforms • We still want object pointer alias for performance reason (call-by-value is too costly for argument that contains large objects)

3. Some available solutions (1) • Java’s loader model • Mistrusting programs in distinct loader spaces can only communicate with each other through serialization. It’s slow! • Shared system classes are potentially dangerous

4. Some available solutions (2) • Guarded object • Guard object check permission before giving out reference of the guarded object • No way to protect against errors in the guard object’s code • Once the reference is given out, it can not be easily revoked

5. Some available solutions (3) • Class-based alias control techniques • Different instances of the class might have different security policy but are treated uniformly in this approach • Can only enforce static security constraints

6. Object Space Model • Each object belongs to a space • An access matrix determines whether a space has right to access another space • The access matrix could be updated by “grant” and “revoke” operations • Objects in different spaces might “name” each other , but access right is checked upon method invocation

7. Root S1 S2 S3 S4 The Space Hierachy • Tree structure with a “RootSpace”, and each space can create child spaces, every object is created in one particular space

8. Access Rights among spaces • Default: parent has access to its child spaces, and a space has access to itself • Granting rights: • a parent can grant any space the rights to its children • a parent can also grant right it has to its children spaces • Revoking rights • a parent can revoke rights to its children from any spaces • a parent can also revoke rights that its children had • revoke has chain effect to the descendants

9. Root client1 client2 server Examples – Program Isolation

10. Root Root Traditional guarded object Java guard object client client Guard Guard G-Obj G-Obj Examples – Guarded Objects

11. Root Root user1 user1 user2 server user2 server packet packet Examples–Server Containment Server’s right to packet is revoked by user1 after service

12. Implementation - API • IOSObject – contains a pointer to the space the object belongs to • Space – implements operations, such as createChildSpace, grant, revoke, newInstance and checkAccess • RemoteSpace – prevents leaking handle for a space to objects in different spaces

13. Implementation - Bridge • Surprise, surprise, if we can “name” objects from different space, how do we guarantee that every method invocation on an object will do proper security check? Answer is a level of indirection through bridge objects • Objects that are referred cross-space are actually bridge objects. The bridge objects are transparent to programmers.

14. When are the bridge objects used? • When parent space creates an object in its child space, it gets a bridge object handle (newInstance) • When a method call has argument objects from different spaces, they are transferred to bridge objects before passed into the method • When a method returns an object, the result needs to be transferred to a bridge object • Exceptions are caught and arguments are transferred to proper bridge object

15. Implementing Bridge Class • Every class C has a Bridge class Bc < C • Every object gets a bridge object for every outside space that refers to it. The bridge object contains pointers to the protected object and its space, as well as the space that is using the object • Bc insures the following for every method in C: • Perform security checks using the access matrix • Convert arguments and result to proper bridge objects • Catch exceptions and convert the argument to proper bridge objects

16. Space 2 Space 1 O1 O3 O2 O4 Space 3 O5 Bridge Objects

17. Problems: final and private clauses / system classes • Bridge class Bc is a subclass of C, so the object space program either has to reject classes that contain final or pirvate clauses, or has to remove the modifiers from class files before linking • Some system classes, i.e., Object, String, Integer etc., contain final methods. They need special treatment

18. Problems: field access • Field access to the object in a different space is actually field of the bridge object which does not contain anything • One solution is to convert field access to method calls

19. Problems : static methods and fields / native methods • Static methods and fields are security holes. There is no way to rewrite to provide a level of indirection • No guarantee on the behavior of native methods • Reject both

20. Problems : arrays • Element selection “[]” is not a method call • Make local copies when array object is referred across a space boundary • Each element in the array is modified to be the proper bridge object • To share an array, wrap it in a class that has entry selectors as methods

21. Problems : Synchronization • synchronized statement will mistakenly synchronize on bridge objects instead of the original objects • synchronized methods invocation will be directed to the original object through the bridge object

22. Performance evaluation • More efficient than copy-by-value model, especially when the size of object used across domain boundary is large • Some cost for creating bridge classes and loading them

23. Related work • Java’s loader mechanism • Capability object in J-Kernel • JavaSeal • Real-time Java • SecurityManager • Jflow • Alias control

24. Discussion • Is the tree-like space hierarchy natural to programmers? • Do you like the idea of everything being checked dynamically? “Your program compiles, but you have to run it to see if it works.” • How to describe the set of security policy that could be enforced in this model? • Loading bridge classes is insecure and inefficient