Lex,

This is a really interesting proposal. I found it very enlighting and it
raises a number of interesting issues to discuss further. My major complaint
about the proposal is really what needs to be implemented by proxies, e.g.,
will it require a zillion of different proxy classes for each and every
capability, plus all the possible permutations?! There are numerous things
that need to be caught here such as the common resource access capabilities
(file, network, process, etc), the more general development capabilities
(compiler access, primitive availability), up to very specific Squeak
capabilities (who can use #become: or #perform: with specificly which
objects, etc).

For the purposes of running SandCastles I would personally like to have
somewhat more generality along the lines of a Factory pattern. E.g., a
SandCastle can request the rights it needs from some capabilities factory
which itself holds more powerful rights (like the access rights to a number
of files) so that for instance - when read access to a file is requested - a
file stream which was opened read-only is returned [Side note: prototypes
might prove very useful here - one could simply replace known critical
methods such as #primitiveXYZ: with some error generating stub, so that the
factory could actually tailor the object with respect to the specific rights
granted]. Also, if a SandCastle would initially request all the rights it
needs by some authority, this authority might inform the user to give
him/her a chance to grant or deny these rights (e.g., if these rights exceed
the default rights granted to SandCastles).

It might also be interesting to think about a validation mechanism for an
entire image (the last defense from the VMs point of view). One idea would
be to associate a secure hash with an image which is only updated if there
is an explicit capability available in the image. This capability could be
invalidated whenever a SandCastle is loaded so that even in the eventual
case that some SandCastle writes out the image (which could be the worst
case since now it's resident) it would not update the - somehow computed -
hash contained in the image. So that, if the given image is restarted
afterwards, certain master access rights (which would need to be re-aquired
upon image startup) can not be regained without asking the user. Generally,
I like the idea of access tokens for classes of operations which need to be
granted by the VM - what do you think?! Issuing global access rights for
sockets, files, directories, and other resources should give us a pretty
good fence if these could just be dropped when a SandCastle comes in (they
can always be reaquired by asking the user).

I also think that some sort of token will be required for a number of
primitives. As an example, I would like to deny a random SandCastle to use
Object>>become: or Behavior>>addSelector:withMethod: but I would still like
to have a Workspace where I can basically run arbitrary ST code. Since the
compiler will eventually make use of the above mentioned methods some means
of authorization are required, stating that it is okay for Compiler to use
these methods but not for any other code in the SandCastle. Any ideas on how
to make this work?!

Finally, one thing that I didn't really understand in your book: It is not
entirely clear to me why a space of shared immutables is needed. I'm
assuming that this is mainly for speed but is a shared immutable space
really necessary?! If those objects do a) not define capabilities itself and
b) not define pointers to other objects there should be no means by which
one can create a reference from the sandbox to the main image. Therefore
bypassing the proxy should be pretty much impossible. Do you see any other
reason for having the shared immutable space?!

  - Andreas

> -----Original Message-----
> From: Lex Spoon [mailto:lex at cc.gatech.edu]
> Sent: Monday, April 10, 2000 3:21 AM
> To: squeak at cs.uiuc.edu
> Cc: recipient list not shown
> Subject: implementing sandboxes with capabilities
> 
> 
> I wrote up a little document on a capabilities approach to 
> sandboxes in
> Squeak.  I did it in a BookMorph just to try it.  People can view it
> like this:
> 
> 	'http://www.cc.gatech.edu/~lex/squeakcaps.morph' asUrl 
> 		retrieveContents contentStream 
> fileInObjectAndCode openInWorld
> 
> It was fun being able to just grab an ellipse and dump it on my page. 
> On the other hand, I wouldn't want to repeat this right now for any
> document that was longer than this....
> 
> Lex
>