[Opensim-dev] Authentication, take 2: Capabilities

[Diva Canto]

[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.