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
|