[Opensim-dev] Protecting Inventory From Malicious Regions

[Haravikk]

> On 24 Jul 2017, at 13:14, Michel Beauregard <gimisa at yahoo.fr> wrote:
> 
> There is always a delicate balance between security and freedom. 

True, but the idea behind this proposal is improve security without having to sacrifice any freedom at all; the intent is to establish trust, or rather eliminate the need to trust a region at all (at least when it comes to any kind of permanent damage).


Basically the threat posed by a malicious region is the same as any man-in-the-middle attack, whereby the region is expected to pass along a message from the user's viewer to one or more grid services such as the inventory system. A malicious region can change those requests, or even create requests of its own that do something nasty. By signing the requests (or some related message) in the viewer however it becomes impossible for the region to change that message without causing the grid service to refuse it. This way at most all a malicious region could then do is refuse to pass along the messages.

So the only freedom that would be infringed is the freedom for a malicious region to ruin your inventory, which I think is a fair trade 😉

The only really downside is that (on top of the work required to actually implement it) you'd have to wait for grids, sims and viewers to be updated before the feature could be transitioned to a requirement, as until then it'd need to be optional to avoid breaking everything.

> I am not sure if the following is a good link to check  .
> Anyway  If not helpful  simply disregard :
> 
> https://github.com/M-O-S-E-S/moses <https://github.com/M-O-S-E-S/moses>
This is interesting, but I'm not sure if it solves any similar problems; it looks like it still relies on having a secure LAN with the sims and grid services on it, I'll take a look in more detail but I think it's mostly focused on avoiding external threats and sandboxing some of the processes, rather than rogue simulators.



There is one problem area I've thought of that signing consent may not protect against; this is when handling attachments. Since these are rezzed within a region, and logging out or teleporting away would need to give consent to save your attachment(s) it's still possible for some damage to be done, for example deleting the contents of your attachments, changing the colours etc. so that they're saved to inventory in a ruined form. The damage would be limited only to attachments you're wearing though, which is some consolation.

Not quite sure what the solution to that would be, as simulators need these capabilities in order for scripts to work. It's possible this would need to be addressed as a separate issue, but I have some ideas:

Script Capabilities: Basic idea is that scripts would somehow carry a list of capabilities, e.g- change colour, remove prim inventory etc., possibly detected at compile time and attached automatically. When the user arrives in a region they'd provide consent for these capabilities on the relevant attachments only. This means for example that if an attachment can only change colour, then a malicious region couldn't do anything else to it or else when the object is saved it would be detected. Problem with this is it would require the inventory server to process attachments and compare them to the old version, which is pretty overkill, it would also offer no protection for attachments where the scripts take advantage of a wide range of capabilities (as this means the malicious region would have them as well).
Semi-automatic: A variation of this could be to allow objects to be tagged with some kind of locking method. For example, if a scripted object should only change when touched by the owner, then it could be locked to owner touch only. Thus any attempt to change an object without it first being touched by its owner would fail. This idea is similar to how anti-popup systems work in browsers (a site can't open a new window unless the user did something to trigger it). An advantage of this method is that the viewer can keep track of whether the attachment was expected to change, and thus only issue consent to save for those that did, which limits the scope for damage down from all attachments to only those whose requirements were met. Disadvantage of course is that attachments would need to be locked in the correct way (or at all) which means all existing attachments would be unaffected, though it may be possible to do it automatically based upon the events that each script has (is it possible to detect every event that a script supports?)
Rollback: Probably the simplest idea is that the inventory server could keep track of attachment versions over time, allowing the user to potentially roll-back to an older version of the attachment in case something is damaged. This could also be done for no-copy items (since they don't leave a copy behind when you rez them), so may be worth doing regardless.
Client-Side Attachments: Instead of attachments being sent to regions, they'd be hosted by the viewer of the avatar that's wearing them, this means that any scripts would run locally on the viewer, and thus all changes to the attachments would originate within the viewer as well, with the region just maintaining a copy of the actual prims that it can sync with changes from the viewer, and pass on to other agents (so they can still see your attachments). The main disadvantage of this that script byte code would end up in the viewer, which is a huge breach; it might be fine for specific scripts intended to run on the client, but probably rules this option out.
Off-Sim Attachments: This idea is similar to client-side attachments, but essentially the idea is that a grid would somehow designate simulators for use as attachment "hubs"; instead of having an avatar's attachments run on the regions they visit, their attachments would instead run within these hubs. Regions would instead only see a copy of the prims that make up the attachment, receive updates of any changes, and pass in any events and such that the attachments might respond to. The attachments meanwhile would think they're on the destination region, even though they're not. The advantages of this approach is that changes to an attachment can only either come from the attachment hub (as a result of a script) or from the user's viewer (as a result of them editing the attachment), meaning that in the latter case a signed consent can still be used to ensure the region can only do as requested. In terms of hyper-grids in particular this option effectively puts attachments in a similar wrapper to everything else, since the attachments would never leave the grid where the inventory server resides. There are several disadvantages though; first is complexity, there is also potential lag since updates need to be transmitted, and the hubs need to somehow manage load. Otherwise, the big roadblock is that grids would need to somehow allocate (and have available) simulators for this purpose, though for hyper-grid use the simulator where your attachments reside could simply be the last one you were in before you left the grid. This could be nifty for people who user the hyper-grid from their own standalone personal grid, since your attachments would never leave your control, and any scripts within them could run as fast as you like (though it would still be up to the target region how quickly any updates take effect).

Option 4 is my favourite, but also by far the most complex; with that in mind I'd probably lean towards option 2 in the short-term, as it provides a safety net for damaged attachments, with a view to something more complete in future. It's something that would also be very useful to have anyway, as it could also be used to recover from irreparable damage done a no-copy object by restoring it to the state it was in before you rezzed it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20170724/77404a47/attachment.html>