[Opensim-dev] Authentication, take 2: Capabilities
Justin Clark-Casey
jjustincc at googlemail.com
Thu Feb 26 20:41:09 UTC 2009
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.
Ah interesting point - I hadn't considered this before.
>
> 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).
I guess the obvious issue here is that while this isn't an issue for hypergrid, in an open grid environment the user
service becomes a potential bottleneck, though perhaps one which is fairly easily scalable (just load balance over
multiple user services). There would also be an extra delay when region crossing/teleporting while messages are
exchanged with the trusted component over the network. What do you think about this?
>
> *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.
Interesting. I can't remember if the last time this was switched on the whole thing wasn't working or whether just some
particular aspect of it was broken. I suspect it was the latter.
>
> *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
>
--
justincc
Justin Clark-Casey
http://justincc.wordpress.com
More information about the Opensim-dev
mailing list