ObjectSpaces

Hi,

I would like to present a simple concept "ObjectSpaces":
grouping all objects inside  an objectspace, each time
that we send a message to another OS each of the
OSes will intercept the message.

The first usage for me was for process isolation and having
a way to know to what process objects belong. But we could
use them as a security layer between each isolated
processes (in the sence of unix not threads), we can use
them as a recursive definition of process (a process inside a
proces inside a ... ;-) I've made a prototype where I use them
as sandbox and actor model by using the fact that a Space intercept
the messages. We could use them as a reflective
 boxes (a la metaxa or metajava). I guess we could use them as kind
of transactional worlds (i.e. Worlds: Controlling the Scope of Side Effects
http://lambda-the-ultimate.org/node/3040). Another usage is
to scope of the reflection to a space I've made a prototype of it
too you couldn't get all the external instances (that belong
to another space) of a class. And I guess there are much more
possibilities ;-) I've in mind a module system, ...

I've made several implementation of the OSes  the most advanced
had multiple object tables and threaded interpreter but there were
too much bugs inside it ^^ But that was funny to do. The most recent
puts an hidden instance variable inside each objects (which is fine for
a prototype implementation)

Cheers,
Gwen

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 10/20/2010 11:47 PM, Gwenaël Casaccio wrote:
> Hi,
>
> I would like to present a simple concept "ObjectSpaces":
> grouping all objects inside  an objectspace, each time
> that we send a message to another OS each of the
> OSes will intercept the message.

This will need to go for performance reasons.  However, maybe it's
enough to have some _primitives_ redirected to the father ObjectSpace
when the child ObjectSpace causes them.

Also, an ObjectSpace should be able to create another OS from scratch
(you have an image loader written in Smalltalk, right?) rather than only
as a clone of itself.  This is important for sandboxing, and allows the
child OS to have no references to objects in the parent (while the
parent can have arbitrary access).

On the other hand, it adds complexity for the VM because the classes
will have a different OOP for each ObjectSpace (and symbols too, but
maybe those could be shared if we decide that it's impossible to change
an object from read-only to read-write).  Context switches don't have to
be extremely fast, however.

Alternatively, or in addition to this, ObjectSpaces could send events
between themselves.  This allows to implement an actor model.

> I guess we could use them as kind
> of transactional worlds (i.e. Worlds: Controlling the Scope of Side Effects
> http://lambda-the-ultimate.org/node/3040).

Yes, that makes for very easy atomic loading.

> I've made several implementation of the OSes  the most advanced
> had multiple object tables

Multiple object tables are the way to go.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 10/21/2010 12:09 AM, Paolo Bonzini wrote:
> However, maybe it's enough to have some _primitives_ redirected to the
> father ObjectSpace when the child ObjectSpace causes them.

Thinking more about it, you can just replace the methods that call
primitives, so that they first consult the parent ObjectSpace.  You can
then use the existing trusted/untrusted mechanism to avoid _definition_
of new primitives.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Concerning the ObjectSpace model and its interaction with Smalltalk
I was wondering if we could not be inspired by the microkernel:

 - a service for process management
 - a service for the classes
 - a service for security
 - a service for the filesystem
 - ...

An advantage of this approach if a service die we could reload it.
Another point about the OSes and classes, I am not sure if it is
the nice model but I think that an OS has its own environment (i.e.
Smalltalk), there are two possible ways to go: we share some
kernel classes, we don't share

1) sharing model:

We can give to the OS a complete environment with the classes. There is
a stupid problem with subclasses (Object subclasses should only give you
your  subclasses) and also what happens if you change the class format or
method dictionary.  May be kind of VirtualClasses are a nice model for that
kind of work. Or maybe it is another way to manage classes

And off course in a shared model it should be possible to create a fully
sandboxed environment.

2) we don't share:

If we don't share each OS has its own full environment for me the problem
is what happens if we want to communicate, that means that we share at least
the symbol without that any try to send a message to another space will fail.

3) The best of both:  a way to do it is the share the kernel classes
(Object, Behavior,
Metaclass, ...) and make them in a read-only OS.

In term of security sharing classes or not change nothing, we need a safe
way to build classes because the virtual machine knows the format and
needs a correct instanceSpec, method dictionary or correct compiled method.

These points are just ideas, I like the idea of virtual classes, in
fact with the OS
environment we don't really need them. There will be a service which stores some
classes and when we build a new OS we will asks that service and it
will copy the
classes and link them with the kernel classes (which are R/O and should stay R/O
for most of the users)

Sorry this is not clear, but these points are questions that I've in my mind,
I am open to any critic and comments.

For the sandbox mode we should be careful because this is not because we have no
access to external ref that the system is safe:

 - create bad formatted cmpMethod, classes
 - thisContext become: nil
 - thisContext parentContext: thisContext
 - finalization is dangerous too
 - primitives should be restricted : ObjectMemory quit :D
 - memory ressource

On Thu, Oct 21, 2010 at 10:10 AM, Paolo Bonzini <[hidden email]> wrote:
_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Oh I forgot to say we could implement nicely selector namespaces  with that.

On Thu, Oct 21, 2010 at 1:49 PM, Gwenaël Casaccio <[hidden email]> wrote:
_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 10/21/2010 01:49 PM, Gwenaël Casaccio wrote:
> Concerning the ObjectSpace model and its interaction with Smalltalk
> I was wondering if we could not be inspired by the microkernel:
>
>   - a service for process management
>   - a service for the classes
>   - a service for security
>   - a service for the filesystem
>   - ...

Hmm, security, process management and some kind of object system are the
main three responsibilities of the microkernel.

In a shared model it will be _very hard_ to have a sandbox though.  It's
very easy to make things leak from the "outside world".

> 2) we don't share:
>
> If we don't share each OS has its own full environment for me the problem
> is what happens if we want to communicate, that means that we share at least
> the symbol without that any try to send a message to another space will fail.

Yes, some things should be shared, but it should be the bare minimum.
Some classes in particular must be shared (SmallInteger, Float, Symbol,
UndefinedObject, etc.) and also some objects (Processor, nil/true/false,
the symbol table; Smalltalk can be always the first object in the object
memory).  We should remove hard-coded references to _gst_xyz_class as
much as possible.

Some primitives can simply be disabled when running untrusted.  In other
cases, dangerous classes simply should not be shared.  This way, a safe
FileStream can simply be a proxy to the "real" FileStream in the parent
OS, with security checks interposed.  A lot of C code is removed from
the attack surface this way.

IMO, it's up to the parent to decide whether to share.  It can go from
"as little as possible" (sandboxed browser) to

> In term of security sharing classes or not change nothing

Security is not only about crashing the VM, it's also about exploiting
the privileges of the parent OS (which is also more interesting if you
actually want to do something to the host).  The attack surface is much
larger when the parent OS is entirely visible to the child OS.

> These points are just ideas, I like the idea of virtual classes, in
> fact with the OS
> environment we don't really need them. There will be a service which stores some
> classes and when we build a new OS we will asks that service and it
> will copy the
> classes and link them with the kernel classes (which are R/O and should stay R/O
> for most of the users)

I think you're running too fast. :)  Looks like an excessive amount of
abstraction.

You should make a list of possible uses for OSes, with their minimal
required feature set (which communication model? what are the security
implications? etc.), and try to define something that fits all of them.
  It should also fit the VM by the way. :)

 From the VM point of view, all I know right now is that there's a lot
of work that can be done now to limit the VM's knowledge of the system.
  This is a useful improvement anyway.

> For the sandbox mode we should be careful because this is not because we have no
> access to external ref that the system is safe:
>
>   - create bad formatted cmpMethod, classes

For CompiledMethods there is a verifier.

>   - thisContext become: nil
>   - thisContext parentContext: thisContext

Sending methods to thisContext should be forbidden in an untrusted
environment.

Making more validity checks on contexts (when sends are made to
thisContext) or #become: is a good thing anyway.  There's no reason why
the VM should allow (some kinds of) cross-shape #become:, or #become:
that may cause out of bounds instance variable accesses.  #become: in
fact has the same power as #changeClassTo:, because it allows to run a
method compiled for class A with a "self" compiled for class B.

Even with this, there are a lot of problems remaining.  For example we
should add a recursion limit and make sure it handles stuff such as:

Eval [
     x := {#perform:withArguments:. nil}.
     x at: 2 put: x.
     nil perform: #perform:withArguments: withArguments: x
]

which creates no contexts but still overflows the C stack.

>   - finalization is dangerous too

Why?

>   - primitives should be restricted : ObjectMemory quit :D

Yes, untrusted contexts cannot access primitives in new methods, and the
parent can control the primitive methods before starting the child.

>   - memory ressource

You mean CObject?  That's just primitives as well.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 10/21/2010 02:08 PM, Gwenaël Casaccio wrote:
> Oh I forgot to say we could implement nicely selector namespaces  with that.

Selector namespaces are a mess.  I don't think it's possible to get them
right as soon as one class in namespace B is derived from one in
namespace A, and the superclass defines a namespaced selector.

Steer clear of them.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk