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