<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Here's the thing: the CAPs giver can define whatever it wants as CAPs
providers. So I think what we have currently is a subset of what I'm
saying below. Specifically, the CAPs giver can delegate CAPs to trusted
regions.<br>
<br>
But obviously, we need to think more about this. My main goal here is
to flip the tables and see what under.<br>
<br>
Melanie wrote:
<blockquote cite="mid:49A6FE24.1010800@t-data.com" type="cite">
<pre wrap="">It sounds complex, and also sounds like something that would
overcomplicate scenarios where there _is_ trust. It would be great
for a "untrusted grid" scenario, but how would a trusted grid
scenario (e.g. walled garden) be built to be more efficient and less
bottlenecky? This setup creates a SPF for every user. Not good.
Becoming disabled/unresponsive because the user server or home
region fails? that is more brittle than LL!
Melanie
Diva Canto wrote:
</pre>
<blockquote type="cite">
<pre wrap="">[Warning: long and heavy-duty stuff here]
So, I just had an insight this morning as I woke up. We've scratched our
heads about this fuzzy black-box component called "the viewer", and how
horrible it is for open systems because it assumes the regions proxy all
the security-critical data etc etc.
Well, the insight is that maybe this black-box component is not as bad
as we think; maybe we're just not using it the right way. All our
knowledge has come from poking at it with things like gridproxy and best
guesses, which has taken us a long way. But none of us has seen what it
actually does. I still don't know what it does, but now I'm convinced we
can go a lot further with this viewer in order to make it safe in open
systems. I'm hopeful, at least :-)
The key: capabilities.
The implications to OpenSim: enormous.
First a bit of history about CAPs in OpenSim.
From what I understand, CAPs in OpenSim has been a reactive process of
"The Lindens added X over CAPs; let's find the simplest possible thing
that makes the client happy." As a result, when I first started looking
at TPs etc. there was one single CAP seed per agent that was passed
around throughout all the regions that the agent visited, and that was
used to set up CAP URLs with virtually identical paths. The use of
capabilities as security devices was completely defeated; yes, the
client wasn't unhappy, it worked, but we were far away from implementing
CAPs-as-secrets.
Then I started fiddling with that, and changed things so that each
region has its own CAPs seed per agent. However, the purpose of CAPs for
security is still completely defeated, because the regions know each
other's seed caps. In fact, seed caps are being generated by the
departing regions for the receiving regions so that we can implement
agents transfers the way we do now:
eq.EnableSimulator(reg.RegionHandle, endPoint, avatar.UUID);
eq.EstablishAgentCommunication(avatar.UUID, endPoint, ***capsPath***);
eq.TeleportFinishEvent(reg.RegionHandle, 13, endPoint, 4, teleportFlags,
***capsPath***, avatar.UUID);
The departing region that runs the code above needs to know the caps
seed path of the receiving region, so it can send it to the client.
Again, completely defeats the purpose of CAPs being secrets.
Let's rewind. The idea behind caps is that they are opaque URLs that are
a shared secret URL between the CAP giver, the CAP receiver, and the
CAP-function provider. The CAP receiver is the viewer. The viewer
understands (i.e. has semantics for) a number of capability-enabled
functions such as the seed itself, Event Queue, NoteCard and Script
updates, ... and, yes, even Inventory access! As far as we know, the
semantics is defined by a mapping from pre-defined names to the CAP URLs
that we send to the viewer. For example, whenever the viewer wants to
update a notecard in the agent's inventory, it simply posts to the URL
we gave it associated with the name "UpdateNotecardAgentInventory". The
viewer doesn't know what's behind that URL; that's up to (a) the
capability giver to establish who the provider is and (b) to the
capability provider to implement.
OK, so the fundamental flaw in our thinking so far is that the *regions*
are both, and always, the CAPs generators/givers and the CAP-function
providers. (With one notable exception of the initial CAPs seed, which
is generated by the UserLoginService for the first region). This is
flawed because we can't trust the regions in general. We definitely
can't have a single seed being passed around the regions, and we also
can't have the departing region generate the CAPs seed for the receiving
region.
Furthermore, and this is even more radical, we also can't have the
regions post events to the Event Queue! I'll get to this a little
further down.
The right way of thinking, at a high level, is this: the CAPs
generator/giver must be a trusted component. We can't trust regions in
general (only a few home ones), so we can't let CAPs be handled by the
regions in general -- period. In an open grid system we can only trust
the User server, and the servers that it trusts such as the home region
and the user's inventory server. Hence the user server is the only
component that should ever give out CAPs URLs (or delegate that function
to a trusted component).
*Implications*
The implications for how we do things are enormous. For example,
teleports. The right way of doing TPs safely should be to have the
user/presence/homeregion server do them, not the regions. Something like
this:
- client requests TP on the untrusted region A to untrusted region B
- untrusted region A may do whatever it wants with that request, but
let's start by the base case: it complies with the request
- region A notifies *the user server* that the agent wants to TP to region B
- User server posts EnableSimulator for B on *a trusted* Event Queue
- User server posts EnableChildAgent for B on that queue, with a CAP
seed *pointing to a trusted component*, so that precludes B
- Client gets that, and invokes the seed cap to get all the CAP URLs
- User server proceeds to spawn the agent in B
- User server posts TeleportFinish on the trusted queue with that same
CAP seed
- Client does CompleteMovementIntoRegion, as normal
Attachments should also be posted by the User server onto B, and not by A.
[In all of the above, read "user server" as "user server or a trusted
component"; it could be the user's home region, for example; so there
could be only one Event Queue ever, at the home region. Yey!]
Another critical example: inventory. The CAP URL for this should be
pointing directly to the Inventory server, not to the regions. I
understand that inventory over CAPs had some issues in the past. I just
fiddled with it this morning, and it's working -- I'm sure there are
problems that I'm not seeing here on my standalone, but the basics seem
to be there. That is, I gave it this:
m_capsHandlers["FetchInventoryDescendents"] =
new RestStreamHandler("POST", capsBase +
m_fetchInventoryPath, FetchInventoryRequest2);
and the viewer compliantly posted to this URL when I accessed my
inventory, instead of using UDP. So there's something here waiting to be
used.
*Bottom line*
There are still a lot of things that I don't know if/how they work, and
lots and lots of details that are unclear, so I'm not sure this is
feasible. BUT -- I just wanted to launch the idea of turning the tables
upside down on how we do things, using CAPs in a completely different
way than we have been using them. This CAPs mechanism follows the
general idea of moving functions away from the regions, which is our
main goal for secure interoperability. I'm not sure it's "the right"
mechanism, but we really haven't explored it at all.
Your thoughts appreciated, especially from those who have tried using
inventory over CAPs before and from those who know the LL servers from
the libomv end and from everyone else who knows about these things.
_______________________________________________
Opensim-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>
<a class="moz-txt-link-freetext" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>
</pre>
</blockquote>
<pre wrap=""><!---->_______________________________________________
Opensim-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>
<a class="moz-txt-link-freetext" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>