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: > [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 > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev