An Approach to Safe Object Sharing

Ciaran Bryce & Chrislain Razafimahefa

University of Geneva, Switzerland

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)

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

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

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

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

The Space Hierachy

Tree structure with a “RootSpace”, and each space can create child spaces, every object is created in one particular space

Root

S4S3

S2S1

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

Examples – Program Isolation

Root

client2 server

client1

Examples – Guarded Objects

Root

Guardclient

G-Obj

Traditional guarded object

Root

Guardclient

G-Obj

Java guard object

Examples–Server Containment

Root

user2 server

user1

packet

Root

user2 server

user1

packet

Server’s right to packet is revoked by user1 after service

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

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.

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

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

Bridge Objects

Space 1 Space 2

Space 3

O1

O2

O3

O5

O4

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

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

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

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

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

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

Related work

Java’s loader mechanism Capability object in J-Kernel JavaSeal Real-time Java SecurityManager Jflow Alias control

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