Peter Crowther <Peter.Crowther at IT-IQ.com> wrote:
> > From: Lex Spoon [mailto:lex at cc.gatech.edu]
> > It's easy to make a modified compiler which removes booboos 
> > like this. 
> > Things to remove:
> > 
> > 	1. <...> primitives
> > 	2. thisContext
> > 	3. access to the full Smalltalk dictionary
> 
> Having done something this to nail down VisualWorks...
> 
> 4. Ability to modify the Compiler.
> 5. Ability to create your own Compiler.
> 6. Ability to instantiate arbitrary classes and therefore create your own
> methods and fill 'em with bytecodes.
> 7. Ability to become: on methods to swap 'em for others that you've created
> and are waiting in the wings.
> 8. Debug primitives such as instVarAt:put:


I was talking about *compiler* restrictions in this context.  The
problems you mention aren't restrictions that the compiler enforces. 
(At least, not in the system I outlined).  In the system I described,
these attacks would be blocked by not giving raw class handles to
untrusted code.  Bad guys can't call #compile:, and they can't
instantiate subclasses.  They can't modify methods, because they can't
even call #compiledMethodAt: to get a method to modify.

#instVarAt:put: and #become: are actually safe to leave in, except on
proxy objects.  (Assuming the long-standing #become: hole gets fixed,
naturally).


To generalize, the difficulty of oops-as-capabilities is not in denying
access, but in adding back partial access.  It's fairly easy to create a
safe sandbox where people can do nothing but add numbers together.  The
difficulty comes when you start adding back more functionality:

	1. When you add a non-proxy class to the sandbox, you should probably
make it pass the same complier that untrusted code must pass.  And this
means that World, for instance, is no longer available!  Most methods
will pass the complier just fine, but the remainder will take time to
slog through.  (Incidentally, changing from global bindings to Lisp-ish
dynamic bindings appears to solve most of these problems).

	2. When you add a proxy class, you have to wrlite it very carefully so
that you don't introduce any security leaks.


Most of #1 is pretty easy to do, but the sheer amount of code involved
makes it more difficult.  #2 is hard, but there's not a whole lot of it.





> > But in
> > return, you get a much more flexible system.  Your proxies can invoke
> > arbitrary Smalltalk code as they make their decisions.  You security
> > policies can be implemented in Smalltalk code instead of C, 
> > so that you
> > can easily do complicated things like consulting network 
> > databases. 
> 
> I agree that it is more flexible, but it is also *much* harder to verify.
> Crackers are still able to get at functionality provided they can find an
> appropriately tortuous route through the proxies.  I'd be much happier
> running an unknown Squeaklet on a VM with its I/O primitives removed or
> crippled than I would on a fully-functional VM with image-level
> capabilities.
> 

That's true--it's a tradeoff.  On the one hand you get simplicity and
fewer opportunities for holes.  On the other, you get more flexibility.


Lex