[Opensim-dev] [Opensim-commits] r6306 - in trunk: OpenSim/Region/ScriptEngine/Shared/Api/Implementation bin

[Kyle Hamilton]

So, basically, what you're looking at is an attempt to codify the
permissions of a script versus the permissions of the owner.  It's
been my experience that attempting to do all this independently
without all sorts of subsystem-interaction testing leads to nothing
but epic failure.

A case in point: I work with a C language interactive MUD software
called 'fbmuck'.  This software has the property that everything
addressable by the software has one and only one owner... but has
three separate subsystems which deal with permissions to act on
different objects -- which grew out of three separate attempts to
extend the capabilities of the system, at different times in the
development of security consciousness.

The first was the command line.
The second was a programming language (based on Forth). (MUF)
The third was another programming language which is embedded in
printable strings, parsed and substituted at display time. (MPI)

The first was the most limited as to what it could do.  The second was
retrofitted and could do things that the command line couldn't even
hope to do.  During its retrofit and development it was honed and
modified so that certain circumstances could extend or restrict what
it could do in any given invocation.  (This included, in order of
development: Creation of "Wizard" powers, Separation of "Wizard" from
"Mucker", further striation of "Mucker" into 3 privilege levels,
restriction of what parts of MUD-level objects each Mucker level could
affect and how, the creation of new primitive functions that couldn't
fit well into the three-plus-one layer striation, and the creation of
a list of "these functions are too dangerous" functions which could be
blocked at compile-time.)

The third was developed over ten years later, when one of the
interfaces to the MUF programming language was found to be extremely
abusive of CPU power and cycles.  Until this point, if someone wanted
to programmatically and automatically alter their descriptions
(remember, this is text-based) based on a small set of variables, they
had to invoke a specific program from their description property.
Quite simply, the burden of starting up an interpreter instance was so
prohibitive, it became necessary to create something that could be
simply embedded, and be able to be parsed by the MUD software much
more efficiently.  The designer of this language created it to be
aware of the security of the MUF language, and put a lot of thought
into making it work within the strictures without granting additional
privileges.

This worked wonderfully -- until it was found that there was a way to
code using the third language that could write to a property that was
prohibited to the second language, and thus caused the third language
to later interpret that string in a different security context than
the one it originated in, and created the means for a virus to be
written.  (It was the first known virtual-world
association-transmitted disease -- if you looked at someone whose
description was infected, your description became infected.)

This would have been prevented if there had been a single point of
failure, a single point where authorization to perform any action
would pass or fail.

So, the point of my long-winded rambling is this:

If you're going to develop something like AllowScriptFunction(), could
you please please please factor it out of the scripting engine,
genericize it (based on what operation is being attempted by what
script owned by who and run in what security context against what
other object owned by what person and probably a hundred other things
that I'm not thinking of right now), put it in the security management
framework, and make everything that can manipulate other things call
it?

I only ask/suggest this because I know how difficult it is to change
something in a code base once it's entrenched.  I've been fighting (in
fbmuck) to separate out what privileges are needed for various
primitive functions, and it's possible that it's too tangled a mess to
ever separate without sacrificing backward-compatibility.  I think
that exploits against OpenSim's ownership model -- in any form --
would be the worst possible condition.

-Kyle H

On Mon, Sep 15, 2008 at 8:45 AM, Sean Dague <sdague at gmail.com> wrote:
> melanie at opensimulator.org wrote:
>> Author: melanie
>> Date: 2008-09-15 08:25:48 -0700 (Mon, 15 Sep 2008)
>> New Revision: 6306
>>
>> Modified:
>>    trunk/OpenSim/Region/ScriptEngine/Shared/Api/Implementation/OSSL_Api.cs
>>    trunk/bin/OpenSim.ini.example
>> Log:
>> Add more granularity and a risk asessment system to the OSSL API in XEngine.
>> Adds the fix from Mantis #2197 in it's new form.
>> Stage one of the scripting security changes, more to come.
>
> Would it be possible to merge the allow osFunctions preflight test with
> the thread level check so that we could reduce it to a single line of
> "AllowScriptFunction(int type (lsl, osl, future types), int risk, string
>  name)";
>
> Then define the fail case as a set of exceptions:
> ScriptTypeNotAllowed
> ScriptThreatLevelExceeded
>
> or something?
>
> It would drop a bunch of copy and pasted code, which would be really nice.
>
>        -Sean
>
> --
> Sean Dague / Neas Bade
> sdague at gmail.com
> http://dague.net
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>