> On 24 Jul 2017, at 13:14, Michel Beauregard <[email protected]> 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.
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
