[vos-d] s5 scripting (design part 3)

[Peter Amstutz]

Ok, finally have some time to address this :-)

On Sun, Apr 22, 2007 at 02:18:31PM -0700, Ken Taylor wrote:
> So, from a user's perspective, how might the following cases work in an
> Interreality 3D system built upon vos s5:
> 
> 1) Someone running a server wants special behavior from an object, written
> in the scripting language of their choice, to be attached to an object at
> run-time -- but without that code being accessible to clients.

By "code not accessable to clients" do you just mean that clients can't 
see the source, or that in fact other users arn't able to run it, they 
don't have the "execute bit" set, in Unix terms?

Let's answer both.

My current design calls for behaviors to be implemented with VOS 
metaobject types.  A vobject type will effectively be a class, and 
message handlers are methods.  To add a behavior, you define a new type 
and connect your script to the message handlers for that type.

I intend to expose the type system as part of the VOS structure, so you 
might go to /types/mygame/monsters/orc to define the behaviors specific 
to "orc" (which would inherit from the "monsters" type and be part of 
the "mygame" namespace).  Thus, normal vobject security can be used to 
enforce who can and cannot view and/or change the scripts.

The second question is that once you've defined your script, how do you 
restrict it's use to only the objects you authorize?  In this case, we 
can still use the security system, but we either a) have the "add type" 
command check to see if you're allowed to add it or b) adding a type to 
a vobject means you ask the type vobject to "bless" your object with its 
behavior.  In (b), you can restrict who can use that type by restricting 
who has has access to your "bless" method.

> 2) Someone connecting to a server with a client "owns" a bit of 3d space and
> can create objects and attach scripts to them. They create a new object with
> some sort of behavior, and they upload the script to that object. What if
> the script had a syntax error? What if the script tried to do something
> illegal or use up too many resources?

This is actually three questions.

2a) If the script has a syntax error, it needs to be reported to the 
client.  I think the best strategy will be to enforce that the 
"scriptable" metaobject type only accept syntatically correct scripts, 
so if you upload a script with an error, you get back a polite error 
message telling you what was wrong.

2b) If the script does something obviously illegal, it should be 
terminated with extreme prejudice.  I'm not sure where the error should 
be reported, although the user should have some indication that what 
their script was terminated.  That said,, my idea for s5 security is to 
use a capability system (which I haven't talked about yet, but I'm 
working on it) which actually makes "illegal" actions impossible by 
design.

2c) Imposing resource limitations is really tough.  There are basically 
three resources that matter: CPU, RAM and disk space.  In a persistant 
system that can swap out objects, we can more or less claim that RAM == 
disk space and main memory is a fast cache.  That leaves us with RAM and 
CPU.  RAM quotas can be enforced by tracking memory allocation/freeing 
requests and having those requests rejected when some limit is exceeded.  
Similarly, the virtual machine running scripts will need some way of 
tracking how much CPU time has been used.  From a computational 
standpoint, is pretty close to the scheduling problem faced by operating 
system designers.  The VM needs to provide a way of preempting a process 
when it goes over, or some sort of enforced yield that compels the 
process to check in and yield at key points in execution.

To do both of these things properly will require some degree of control 
over the virtual machine that is running the script.  This is to be 
expected, mobile code is really hard and has not been well addressed by 
current programming languages and virtual machines.  Java and Javascript 
have mediocre security models that have been considered "good enough" 
but don't really address obvious problems like a rogue scripts that try 
to use as much CPU and RAM as possible.  A lot of this also borders on 
essentially operating system tasks (I have been pondering that VOS bears 
many similarities to classic microkernel design for OSs) so it might 
also make sense to think about ways the underlying OS can be used to 
sandbox untrusted user scripts.

> 3) Someone wants to write a script for their vos-based client that just
> tweaks the interface client-side (perhaps automating some functions or
> creating new UI elements). What if they wanted this script to break out of
> the typical sandbox?

The UI will need to be built from vobjects, and the script would add or 
remove vobjects representing that user interface elements to provide 
controls which ran your scripts when activated.  In terms of security, 
changing user interface elements is one of the primary tasks that 
scripts will be used for, and so they should be allowed to do it.  
However, for breaking out of the sandbox in general, with a capability 
system we can grant relatively narrow and specific rights to a script 
that requires escalated privilidges.

> 4) An object on the server contains a script to be run client-side, perhaps
> to perform some special animation effect or to support some custom
> interaction with the server, and the user of the client can decide to accept
> that script or not.

I haven't decided how to handle sending code from the server to the 
client.  One approach would be to go to the relevant type vobject on the 
server and retrieve the "remote interceptor" which provides the remote 
vobject behavior that acts as the proxy on the client for the real 
vobject on the server.

Everything I have said here about server-side process accounting, 
resource limits and security applies equally to both the server side and 
client side.  You don't want a malicious script to take over your 
desktop any more than you want it to take over a server with hundreds of 
people on it.  The main difference is that on the client side we have 
the option of asking the user if something is acceptable, instead of 
just rejecting it outright.  Deciding whether to actually run a script 
based on some client preference (maybe it's an annoying dancing 
advertisement) rather than having evidence of the script misbehaving is 
rather more difficult.

> Also: will interreality specify any "default languages" to be supported as a
> baseline, or will it just be whatever runtimes the current server has
> installed? Will there be a way to query the server for what runtimes it
> supports, and what capabilities those runtimes have? Can an object (such as
> in case 4) have multiple languages attached to it, so the client can pick
> which one it supports the best? Can a script specify at the outset what
> capabilities it requires so the vos kernel can decide whether or not to even
> run it (or to ask the user to allow certain capabilities)?

Yes, we'll want some way of asking the server it's configuration, to 
find out what scripting languages (among other things) it supports.  
Letting mobile code be written in languages seems like a recipe for 
disaster though, since the two implementations were identical (and the 
standard well documented), you might get significantly different 
behavior in one runtime compared to another.  I suppose you could 
translate from one programming language to another automatically, but 
I've never seen that done well...

Since detailed process accounting for CPU and RAM are going to be hard 
to accomodate with existing scripting systems, the idea for the time 
being is to use existing scripting languages, but in a "trusted" 
capacity -- we might enforce the VOS security model for vobjects, but 
not worry about so much about CPU, RAM and disk usage.  This should 
allow us to support a few languages on the server right off the bat.  
However, this is unacceptable for mobile code.

For code that is transferred over the network and is run on the client 
or server without user or admin intervention, we will need to identify 
some runtime system that satisfies our strict process accounting and 
security requirements.  This will probably end up being the "default 
language" at least so far as client and server side scripts written by 
untrusted users are concerned.  Ideally this would be a virtual machine 
and not just a single specific language.  I haven't found a good open 
source implementation of a virtual machine that satisfies our 
requirements, yet.

So to sum up, for me the biggest challenge of scripting is to make it 
bulletproof secure, so that it can't be used by either clients or 
servers to take advantage of the other.  I'm hoping to use a capability 
system to enforce security in interactions between vobjects (which I 
will try to do a writeup on soon, that will be part 4 of the s5 design) 
but process accounting to see that everyone gets their fair share of 
CPU/RAM is still a huge challenge.  I don't want my scripting languages 
in a sandbox, I want them in a bulletproof jail cell...

> ps: Something else that may be interesting -- having a special VOS 
> translation layer that lets one run scripts wrtten for VRML nodes in a 
> VOS world. This could facilitate importing VRML files transparently.

Reed and I have been thinking about doing this for years.  The idea was 
to use OpenVRML to provide the VRML runtime environment, and then 
translate VOS events to VRML input and vice versa.  I think it's 
feasable, we've just never had the time to implement it.

-- 
[   Peter Amstutz  ][ tetron at interreality.org ][ peter.amstutz at gdit.com ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey:  pgpkeys.mit.edu  18C21DF7 ]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.interreality.org/pipermail/vos-d/attachments/20070427/3bf958d6/attachment.pgp