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

[Melanie]

Hi,

OpenSim is very much a work in progress. This current stab at 
permissions doeen't even attempt to address this issue in the depth 
that you have explored it to.

It was meant to be a simple true/false, then I incorporated the 
suggestion for a UUID list for privileged users.

This is not about ACLs or scripting rights levels (yet), but just 
about a meant of allowing beneficial os* functions while blocking 
potentially harmful ones.

One grid may see the griefing danger of letting any object animate 
any avatar without a permission being granted.
Another grid may need this feature desperately.

Just deciding which functions would be available and which aren't 
would be very divisive. So I created a common sense base based on 
grids like OSGrid, and then created a system by which it can be 
overridden outside of code.

For the moment, not more is needed. A real ACL system has been 
thought about, but it's nowhere near writing the first line of code.

Melanie


Kyle Hamilton wrote:
> 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
>>
>>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 
>