<!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">
Hehehe. And how's this for hacking in a scale of 1 to 10? <br>
<br>
Unfortunately, the viewer seems to have only a limited set of
capabilities, which is a pain. For example, I wish it had a CAP for
requesting teleports, so that the request would go directly to a
trusted component instead of to the region where the user is. It
doesn't have that CAP, as far as I can tell. However...<br>
<br>
We could use the "UpdateNotecardAgentInventory" CAP to send arbitrary
messages directly to our trusted home system. Just edit a notecard in
Inventory and write, for example `(teleport home), then save the
notecard. That would go through the "UpdateNotecardAgentInventory" CAP
directly to the inventory system, which can then parse the contents
looking for messages in a bottle.<br>
<br>
Hehehe... :-)<br>
<br>
Seriously, the right way of writing the viewer would be for it to
accept capabilities for all of its functions, and default to UDP to the
region if no CAP URL is set. Those 400+ messages of the Client-Server
protocol should simply be handles for capability-like functions that
would be implemented by assorted components, to be defined at
login-time by the trusted home system. But there I go again bashing the
viewer, right after my new-found love for it...<br>
<br>
I'm sure we can make up for the missing CAPs in the viewer with a Web
Interface, as Stefan says. <br>
<br>
Diva Canto wrote:
<blockquote cite="mid:49A821C0.2010807@metaverseink.com" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
I confess I didn't understand CAPs until they hit me in the head
yesterday. I always knew the way we were using them was "wrong" in the
sense that it defeats their purpose of being security devices. Yes, the
viewer doesn't complain, but they are mute for security purposes. So,
really, I'm just trying to find the right story for them in the context
of this black-box viewer, and starting from basic principles. It seems
that there are many ways of managing capabilities, one of them being
what we are doing now. I have no idea how Linden Lab does it; but that
doesn't matter. What matters is that this viewer has some buttons that
we can push -- not all the buttons we would like, but some.<br>
<br>
Maybe capabilities are, indeed, a nifty idea, after one gets passed the
initial "this is way too complicated" phase. Maybe other viewers would
use them too, if we have a simple story for them. I really like their
model of using secret URLs for accessing security-critical services --
that's very nice.<br>
<br>
I still don't understand this well enough to attempt the very needed
comparison between capabilities and OpenID tokens. If someone already
got to that point, please share!<br>
<br>
Stefan Andersson wrote:
<blockquote cite="mid:BLU134-W141E587FDE89046BAA9578D5AA0@phx.gbl"
type="cite">
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>Actually,
I think getting a 'true' CAPS model going (for
those stacks that would use it) would be a major win.<br>
<br>
Getting more user-based stuff moved off the regions as performance and
trust bottlenecks would be a major win.<br>
<br>
Regarding the user/inventory service as a bottleneck, I believe that
it's no better or worse than having the region as one - walled garden
or not, users will come from differing user/inventory servers anyway,
and the ability to load balance those services is just as interesting
as being able to load balance regions.<br>
<br>
One example is that right now, the user can get 'stuck' in an
uncooperative region. As I understand it, with CAPS (if it would work)
you could assure that the user at least always can teleport off an
unresponsive server - even forcibly teleport him off it - which would
be a major win. <br>
<br>
Along the same lines, you could start initiating some actions from a
web ui, which would be a major step forward.<br>
<br>
Getting some people from the sl-dev list to cooperate closely with us
to map out exactly what calls could reliably used over CAPS would be a
major win. (No more guessing games - let's get the facts.)<br>
<br>
Regarding the complexity of the solution, I believe that with the
current modularization that we're moving towards, and if the CAPS
system could be made truly portable over region and grid modules, thru
(customized) streamhandlers (there is an LLSDStreamHandler, actually) I
think that the complexity could be alleviated - simply put, the trust
policy would just be a matter of configuring where the trusted llsd
handlers would be instantiated. If it's on a user server, or on a
region server, I believe that they could use the same set of CAPS
modules, if those modules had an IInventoryService, an IUserService and
an ITeleportService proxy or implementation.<br>
<br>
That said, CAPS as of now is fundamentally a LLClientView thing, so one
probably needs to think about how one would slice that cake.<br>
<br>
But above all, +1 on getting a 'true' CAPS implementation in place. Go
Diva! (Godiva?)<br>
<br>
Best regards,<br>
Stefan Andersson<br>
Tribal Media AB<br>
<br>
<br>
<br>
<br>
> Date: Thu, 26 Feb 2009 20:40:04 +0000<br>
> From: <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:melanie@t-data.com">melanie@t-data.com</a><br>
> To: <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a><br>
> Subject: Re: [Opensim-dev] Authentication, take 2: Capabilities<br>
> <br>
> It sounds complex, and also sounds like something that would <br>
> overcomplicate scenarios where there _is_ trust. It would be great
<br>
> for a "untrusted grid" scenario, but how would a trusted grid <br>
> scenario (e.g. walled garden) be built to be more efficient and
less <br>
> bottlenecky? This setup creates a SPF for every user. Not good. <br>
> Becoming disabled/unresponsive because the user server or home <br>
> region fails? that is more brittle than LL!<br>
> <br>
> Melanie<br>
> <br>
> Diva Canto wrote:<br>
> > [Warning: long and heavy-duty stuff here]<br>
> > <br>
> > So, I just had an insight this morning as I woke up. We've
scratched our <br>
> > heads about this fuzzy black-box component called "the
viewer", and how <br>
> > horrible it is for open systems because it assumes the
regions proxy all <br>
> > the security-critical data etc etc.<br>
> > <br>
> > Well, the insight is that maybe this black-box component is
not as bad <br>
> > as we think; maybe we're just not using it the right way. All
our <br>
> > knowledge has come from poking at it with things like
gridproxy and best <br>
> > guesses, which has taken us a long way. But none of us has
seen what it <br>
> > actually does. I still don't know what it does, but now I'm
convinced we <br>
> > can go a lot further with this viewer in order to make it
safe in open <br>
> > systems. I'm hopeful, at least :-)<br>
> > <br>
> > The key: capabilities.<br>
> > The implications to OpenSim: enormous.<br>
> > <br>
> > First a bit of history about CAPs in OpenSim.<br>
> > <br>
> > From what I understand, CAPs in OpenSim has been a reactive
process of <br>
> > "The Lindens added X over CAPs; let's find the simplest
possible thing <br>
> > that makes the client happy." As a result, when I first
started looking <br>
> > at TPs etc. there was one single CAP seed per agent that was
passed <br>
> > around throughout all the regions that the agent visited, and
that was <br>
> > used to set up CAP URLs with virtually identical paths. The
use of <br>
> > capabilities as security devices was completely defeated;
yes, the <br>
> > client wasn't unhappy, it worked, but we were far away from
implementing <br>
> > CAPs-as-secrets.<br>
> > <br>
> > Then I started fiddling with that, and changed things so that
each <br>
> > region has its own CAPs seed per agent. However, the purpose
of CAPs for <br>
> > security is still completely defeated, because the regions
know each <br>
> > other's seed caps. In fact, seed caps are being generated by
the <br>
> > departing regions for the receiving regions so that we can
implement <br>
> > agents transfers the way we do now:<br>
> > eq.EnableSimulator(reg.RegionHandle, endPoint, avatar.UUID);<br>
> > eq.EstablishAgentCommunication(avatar.UUID, endPoint,
***capsPath***);<br>
> > eq.TeleportFinishEvent(reg.RegionHandle, 13, endPoint, 4,
teleportFlags, <br>
> > ***capsPath***, avatar.UUID);<br>
> > <br>
> > The departing region that runs the code above needs to know
the caps <br>
> > seed path of the receiving region, so it can send it to the
client. <br>
> > Again, completely defeats the purpose of CAPs being secrets.<br>
> > <br>
> > Let's rewind. The idea behind caps is that they are opaque
URLs that are <br>
> > a shared secret URL between the CAP giver, the CAP receiver,
and the <br>
> > CAP-function provider. The CAP receiver is the viewer. The
viewer <br>
> > understands (i.e. has semantics for) a number of
capability-enabled <br>
> > functions such as the seed itself, Event Queue, NoteCard and
Script <br>
> > updates, ... and, yes, even Inventory access! As far as we
know, the <br>
> > semantics is defined by a mapping from pre-defined names to
the CAP URLs <br>
> > that we send to the viewer. For example, whenever the viewer
wants to <br>
> > update a notecard in the agent's inventory, it simply posts
to the URL <br>
> > we gave it associated with the name
"UpdateNotecardAgentInventory". The <br>
> > viewer doesn't know what's behind that URL; that's up to (a)
the <br>
> > capability giver to establish who the provider is and (b) to
the <br>
> > capability provider to implement.<br>
> > <br>
> > OK, so the fundamental flaw in our thinking so far is that
the *regions* <br>
> > are both, and always, the CAPs generators/givers and the
CAP-function <br>
> > providers. (With one notable exception of the initial CAPs
seed, which <br>
> > is generated by the UserLoginService for the first region).
This is <br>
> > flawed because we can't trust the regions in general. We
definitely <br>
> > can't have a single seed being passed around the regions, and
we also <br>
> > can't have the departing region generate the CAPs seed for
the receiving <br>
> > region.<br>
> > <br>
> > Furthermore, and this is even more radical, we also can't
have the <br>
> > regions post events to the Event Queue! I'll get to this a
little <br>
> > further down.<br>
> > <br>
> > The right way of thinking, at a high level, is this: the CAPs
<br>
> > generator/giver must be a trusted component. We can't trust
regions in <br>
> > general (only a few home ones), so we can't let CAPs be
handled by the <br>
> > regions in general -- period. In an open grid system we can
only trust <br>
> > the User server, and the servers that it trusts such as the
home region <br>
> > and the user's inventory server. Hence the user server is the
only <br>
> > component that should ever give out CAPs URLs (or delegate
that function <br>
> > to a trusted component).<br>
> > <br>
> > *Implications*<br>
> > <br>
> > The implications for how we do things are enormous. For
example, <br>
> > teleports. The right way of doing TPs safely should be to
have the <br>
> > user/presence/homeregion server do them, not the regions.
Something like <br>
> > this:<br>
> > <br>
> > - client requests TP on the untrusted region A to untrusted
region B<br>
> > - untrusted region A may do whatever it wants with that
request, but <br>
> > let's start by the base case: it complies with the request<br>
> > - region A notifies *the user server* that the agent wants to
TP to region B<br>
> > - User server posts EnableSimulator for B on *a trusted*
Event Queue<br>
> > - User server posts EnableChildAgent for B on that queue,
with a CAP <br>
> > seed *pointing to a trusted component*, so that precludes B<br>
> > - Client gets that, and invokes the seed cap to get all the
CAP URLs<br>
> > - User server proceeds to spawn the agent in B<br>
> > - User server posts TeleportFinish on the trusted queue with
that same <br>
> > CAP seed<br>
> > - Client does CompleteMovementIntoRegion, as normal<br>
> > <br>
> > Attachments should also be posted by the User server onto B,
and not by A.<br>
> > <br>
> > [In all of the above, read "user server" as "user server or a
trusted <br>
> > component"; it could be the user's home region, for example;
so there <br>
> > could be only one Event Queue ever, at the home region. Yey!]<br>
> > <br>
> > Another critical example: inventory. The CAP URL for this
should be <br>
> > pointing directly to the Inventory server, not to the
regions. I <br>
> > understand that inventory over CAPs had some issues in the
past. I just <br>
> > fiddled with it this morning, and it's working -- I'm sure
there are <br>
> > problems that I'm not seeing here on my standalone, but the
basics seem <br>
> > to be there. That is, I gave it this:<br>
> > <br>
> > m_capsHandlers["FetchInventoryDescendents"] =<br>
> > new RestStreamHandler("POST", capsBase + <br>
> > m_fetchInventoryPath, FetchInventoryRequest2);<br>
> > <br>
> > and the viewer compliantly posted to this URL when I accessed
my <br>
> > inventory, instead of using UDP. So there's something here
waiting to be <br>
> > used.<br>
> > <br>
> > *Bottom line*<br>
> > <br>
> > There are still a lot of things that I don't know if/how they
work, and <br>
> > lots and lots of details that are unclear, so I'm not sure
this is <br>
> > feasible. BUT -- I just wanted to launch the idea of turning
the tables <br>
> > upside down on how we do things, using CAPs in a completely
different <br>
> > way than we have been using them. This CAPs mechanism follows
the <br>
> > general idea of moving functions away from the regions, which
is our <br>
> > main goal for secure interoperability. I'm not sure it's "the
right" <br>
> > mechanism, but we really haven't explored it at all.<br>
> > <br>
> > Your thoughts appreciated, especially from those who have
tried using <br>
> > inventory over CAPs before and from those who know the LL
servers from <br>
> > the libomv end and from everyone else who knows about these
things.<br>
> > <br>
> > _______________________________________________<br>
> > Opensim-dev mailing list<br>
> > <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
> > <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
> > <br>
> > <br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
> <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
<pre wrap=""><hr size="4" width="90%">
_______________________________________________
Opensim-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>
<a moz-do-not-send="true" 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>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
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>