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

Wed Sep 17 02:20:10 UTC 2008

Hi,

I believe that the levels of security and control you are talking 
about are entirely out of scope for OpenSim scripting as we have it 
now (LSL conform, prim based).

The type of security you are envisioning would introduce things into 
core that should be programmed behaviors in a module. They are for 
certain, specific applications, not for general use. The normal use 
cases don't need an overcomplicated security model, they just need 
enough granularity to achieve a good feature richness/griefer 
protection balance.

Anything else is, I believe, outside the scope of the core 
implementation.

Melanie

Kyle Hamilton wrote:
> My suggestion is that the code be structured such that it be easy to
> build security into, only due to the fact that I have seen a (perhaps
> pathological) case of what happens when it is not.
> 
> Sure, a true/false thing works... but in the fbmuck project, we have a
> call like that: 'controls()'.  This function returns true for the
> owner of the object, any Wizard trying to affect the object, and any
> Realm Wizard (kinda like an estate owner) trying to affect the object.
>  (In OpenSim parlance, each owner/wizard/realm wizard is a user entity
> assigned a different UUID, thus very closely mirroring your OpenSim
> design.)  The interface was, partially due to the language it was
> written in, unable to be expanded sufficiently to handle the other
> kinds of manipulations possible on objects and their properties.  This
> is part of what led to the plethora.
> 
> OpenSim is certainly a work in progress -- but it's got most of its
> structure in place, most of the interfaces that relate to scripting,
> most of the interfaces that relate to object manipulation.  The fact
> is that it got here because of iterative design of the various pieces.
>  But, security has never been abstracted out from the equation.
> Security has never had the iterative design process applied to it.
> There is no interface into any security management system, and no
> interface into any security management singleton.
> 
> If this is outside the scope for the current action, what do I have to
> do to get it on the table for 0.7?
> 
> -Kyle H
> 
> On Tue, Sep 16, 2008 at 2:39 AM, Melanie <melanie at t-data.com> wrote:
>> 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
>>>
>>>
>> _______________________________________________
>> 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
> 
> 