Richie,

> > By definition, a Smalltalk system runs bytecodes and will go through
> > primitives to do any I/O like stuff.
> 
>     This is completely true, but, it's also why we need a 
> different set of primitives for the Squeak plugin.

Why a different set (and what different set)?! I'd say that 90% of the
primitives are pretty secure the way they are (just because they can't even
theoretically cause you harm). 

> With today's primitives, Squeak's plugin  is opening a door to
> everything on your machine/network/mind?

That depends. The basic things you want to have secure are:
* File I/O,
* Socket I/O,
* External (named) primitives, and,
* Image writing.
Is there anything else you could think right of?!

>     This problem has been addressed in Java, I think we should take a
> look at what they have done.
>     Also, releasing this kind of programs (internet clients/internet
> client's plugins/etc) is a delicate thing to do, because 
> there is a huge community of hackers/computer security related 
> people looking for security problems in this kind of software.
> Security is something to have in mind (or else somebody else 
> will remind you) when you release an internet client.

I certainly agree.

> > The only thing that's relatively easy to do in a Smalltalk 
> > system (and a little harder in Java) is to crash the VM 
> > (though this could be made harder by a VM level code validator).
> 
>     You are talking about creating an Object that points somewhere in
> memory (outside squeak's ObjectMemory),

No, actually not. What I was talking about was something like

	[thisContext instVarAt: 2 "pc" put: 99999 "that'll never do"]

> lets say a ByteArray who's elements are in process Stack 
> (not Squeak's VM's Virtual stack, but Squeak's VM "C" stack),
> then you can insert some (native) code into this
> stack, and change the return address of any function in the 
> [let's say] VM.c file, and when that function returns, 
> the microprocessor will start executing your native code.

You can't do any of this without going through primitives (at least AFAIK,
if one could that would be a *serious* security leak). But if you have to go
through a primitive you can again make sure this doesn't happen.

>     We (at Core) have been thinking about this issue, and we 
> think it's not easy to solve, without adding an indirection on 
> the VM, or checking every access to "object's pointers" against 
> a valid range of addresses.
> 
>     Am I right? what do you think?

I don't think you are right. Please try to give me an example where you
don't go through any primitive that can be trivially secured (e.g., don't
use the FFI - this one will *never* count as secure ;-) I would even argue
that you can't even create an oop from within Squeak that points somewhere
outside Squeak memory. If you can, please show us how.

  Andreas