implementing sandboxes with capabilities

Robert Withers withers at vnet.net
Wed Apr 12 06:15:49 UTC 2000


Hi Ted,

If we treat every object as belonging to a space then the Mum and the
Ear could become the same wrapper from the two sides of a barrier.  I
think of this barrier as a membrane between two spaces.  Whenever an
object is bound externally, it will wrap itself in a Proxy.  Whenever a
message send occurs, the arguments are wrapped in Proxies.  Same with
return values.  If you look at my AddressSpaces, I wrap external
references, and return values from message sends, but I am not sure
about the arguments.  I'll look into that.

On your other post, you mention changing the interpreter - could we do
this without a change there?  It would be more easily cross-dialect, and
that might be very useful for this particular feature.

Rob


"Ted K." wrote:
> 
> Lex,
>         Here is another cut at the whole thing, trying to make it simpler.
> 
> All objects are divided into these four groups:
> 
> * Regular Squeak objects.
> 
> * Sandbox objects.  These are instances of classes defined in the Sandbox.
> The code in these classes is under the control of evil terrorists.
> 
> * Mum wrappers.  When a regular Squeak object ventures into the Sandbox, it
> is always wrapped in a Mum wrapper.  A Mum wrapper does not pass on any
> message that would do harm.  A Mum wrapper never divulges the oop of any
> regular Squeak object.  (Think of there being one Mum wrapper class for
> every Squeak class that needs to be known in the Sandbox.  It defines every
> message that its target understands.  Harmful ones are stopped with an
> error message.)
> 
> * Ear wrappers.  When a Sandbox object is passed around as an argument
> among the regular objects, it is wrapped in an Ear wrapper.  Its purpose is
> to keep the Sandbox object from *hearing* about regular oops.  An Ear
> wrapper passes all messages on to the Sandbox object is represents, but it
> wraps every argument object in a Mum wrapper before sending it in.  (A
> Sandbox object that is passed around as an argument may be sent a message
> with an argument by an unsuspecting regular object.  If the Ear wrapper did
> not intervene, the Sandbox object could send arbitrary bad messages to the
> argument.)
> 
> The goal:  No regular object every receives a message from a Sandbox object
> that would cause harm.  No Sandbox object every learns the oop of any
> regular object.
> 
> A Sandbox object is free to send any message to any object it can get the
> oop of.
> 
> On the Sandbox side, the only oops available are of Sandbox objects and Mum
> wrappers.
> 
> On the regular Squeak side, the oops available are of regular Squeak
> objects, Ear wrappers and Mum wrappers.  (Oops of Sandbox objects are not
> visible here.  Part of the job of a Mum wrapper is to prevent any regular
> Squeak object from learning the oop of a Sandbox object.  We are protecting
> ordinary Squeak code from ever dealing with a dangerous object.
> Programmers writing code for regular Squeak classes do not have to be
> careful about anything.)
> 
> When a regular Squeak object receivers a Mum wrapper as an argument, it
> unwraps it.
> 
> The pure implementation, using real wrapper objects is very clean.  Now
> let's consider SmallIntegers and Characters.  Each of these is a very smart
> a Mum wrapper.   It is so smart, it does not need a real object behind it.
> 
> Mum wrappers can speak no evil to their target.  Ear wrappers prevent
> Sandbox objects from hearing any regular oops.
> 
> I think this could work very well.  Even though the boudary between the
> Sandbox and the main system is complex, the principles are clear.
> 
> --Ted.
> 
> Ted Kaehler,   Walt Disney Imagineering, R&D
> (home) 3415 Cork Oak Way, Palo Alto, CA  94303.  voice (650) 424-1070
> http://www.webPage.com/~kaehler2/
> See exactly what your web browser reveals about your identity
> http://www.junkbusters.com/cgi-bin/privacy

-- 
--------------------------------------------------
Smalltalking by choice.  Isn't it nice to have one!





More information about the Squeak-dev mailing list