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 ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ] [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 ]
signature.asc
Description: Digital signature
_______________________________________________ vos-d mailing list [email protected] http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
