[Opensim-dev] Authentication, take 2: Capabilities

[Melanie]

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 at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 
>