I guess you could do something like this just to do enough to write
a beginning tutorial.  You'd have to audit every method directly callable,
and then every method callable fdrom those, and so on, but I guess it
is doable.  Keep in mind, by the way, that the ~300 methods of Object
will always be available.

Do beware of literals and blocks, however.  For example, you need to keep
people from doing anything to a block other than evaluating it.  Thus
you'll probably want to hack the code that results from [2+2] to not be
a BlockContext, but some other object that only responds to #value.

I'm not sure why 2.8 is such a restriction.  You could write the execution
server in 2.8, and have the rest of the tutorial be in the current
Squeak version.

Spending a couple of days loading Islands, sounds cheap compared to
reinventing even a "simple" security scheme.  Especially when you
consider that Islands was designed to do exactly what you are talking
about: start with a sandbox where nothing is possible but manipulation
of literals, and then carefully introduce limited objects that can be
safely played with within the sandbox.

Furthermore, if you really care about security, then don't forget that
there's good karma from bootstrapping Islands again and uploading
the resulting image and virtual machine.  It provides the groundwork 
for others to update it for Squeak 3.4, and it keeps the squeak-e
group focussed on useful things like making secure Morphic, instead of
reinventing things like how to do limited classes.  It could very
well start a ball rolling that would let the community pay you back
significantly in a year or so.


Lex



On Fri, Feb 21, 2003 at 12:02:39PM -0800, Tim Rowledge wrote:
> >
> > In this case, allowing the assignment and arithmetic expressions is 
> > about
> > all I need.  Later on, there may be certain objects passed in whose
> > protocol they'll get to explore (think Canvas), but I'm a long way from
> > needing arbitrary secure code.  I think what Tim needed was similar - 
> > he
> > essentially wanted to use Smalltalk code as a way of expressing 
> > algebraic
> > equations.
> A bit more than that actually - I want to allow a fairly wide range of 
> expressions without letting nasty minded people trying things like
> Smalltalk quitPrimitive
> true become: nil
> Smalltalk removeClass: Number
> I don't recall enough details right now but I think I was leaning 
> towards a simple class to use as the scope origin along with a few 
> compiler hacks to handle undeclared etc.