[Opensim-dev] The essence of "grid"
Diva Canto
diva at metaverseink.com
Wed Apr 15 22:09:51 UTC 2009
No one but UCI administrators can attach sims to the UCI grid, because
only they know the send/receive password. And as far as I know, only the
admins of, say, K-Grid can attach sims to it.
There's something very special about the way OSGrid uses OpenSim: it
allows uncontrolled region logins to the grid, which is a really
interesting thing to do. Not sure how many other grids do that.
Charles Krinke wrote:
> Backing up a step.
>
> OpenSim does not allow a way to *stop* a region from attaching to a
> UGAIM, be it OSGrid, or any other OpenSim grid. There is nothing unique
> about OSGrid except its history. OSGrid runs the OpenSim software as it
> exists. No more, no less.
>
> I would think the first step would be to have a way to control whether
> or not a region can attach to a grid first before we get too wrapped up
> in other things.
>
> At this point, the only way to stop a region from attaching to an
> OpenSim grid is to put a fake entry into the regions table.
>
> Charles
>
> ------------------------------------------------------------------------
> *From:* Christian Scholz <cs at comlounge.net>
> *To:* lopes at ics.uci.edu; opensim-dev at lists.berlios.de
> *Sent:* Wednesday, April 15, 2009 2:27:31 PM
> *Subject:* Re: [Opensim-dev] The essence of "grid"
>
> Hi!
>
> Cristina Videira Lopes schrieb:
> > I'm trying to understand what it is that we are supposed to secure,
> > because security depends entirely on that :-)
>
> That usually is my problem with most of these discussions be it on MMOX,
> AWG or social networking. So it would be good to have some sort of list
> of what needs to be secured against what sort of action.
>
> > I've seen way too many talks/chats/posts/blogs talking about a Web of
> > VWs in some form, while making the unwritten assumption that the concept
> > of "grid" (aka Virtual World unit, or whatever you want to call it)
> > aligns with the concept of a domain of trust (i.e. a bunch of simulators
> > that trust each other, under the control of one authority). Then, a Web
> > of VWs is the interconnection of those domains of trust.
> >
> > Well, OSGrid doesn't align with that. So either OSGrid is not a
> > valid/sustainable use case for OpenSim or there's something wrong with
> > that unwritten assumption. In my infinite tolerance towards variety, and
> > given the empirical evidence here, I'm leaning towards the latter (i.e.
> > there's something wrong with that assumption).
>
> Unfortunately I am not too familiar on how OSGrid works but I can
> explain how it could work with the scenario I described where we have
> quite many separate services.
>
> In this case a user would login to a region with separate locations of
> the user's inventory, a list of links to group memberships, a link to
> the user's profile and so on.
>
> The region would then ask an authorization manager to get access to
> these resources on behalf of the user. The user will then be asked with
> a list of services the region wants access to and on "ok" this access
> will be granted in form of OAuth access token which can be used to
> perform signed requests to these services. (the concept of the auth
> manager needs to be developed as mentioned).
>
> So in this case the region can only access a user's data after getting
> those tokens. If this "ok" is given automatically though security will
> obviously be lacking.
>
> Now many regions could be grouped into one region domain which might
> mean that they e.g. provide some mapping services and they could maybe
> use shared access to that data.
>
> In the case of a region domain consisting of regions operated by
> different providers this of course means that a rogue sim indeed could
> get access to that data. But in general I don't see a solution here
> unless you really give each sim access upon visiting. Which of course
> would be annoying.
>
> > Yes, OSGrid, as is, will always be extremely vulnerable towards insider
> > rogues; technically, it's impossible to secure OSGrid's UGAIM servers
> > from malicious sims connected to it. But so what? Maybe people want it
> > like that, maybe the OSGrid community wants to perform human
> > surveillance instead of applying technical solutions such as the
> > Hypergrid (once it's matured). Should we stop supporting that use case?
>
> I think in the case of a grid which is operated by many people and you
> don't want just a shared map but also shared access for convenience
> there is not much left for kicking out rogue domains. In fact a user
> might not know that it's a bad sim when entering it anyway so even in
> the case of a confirmation on each crossing that sim would probably gain
> access.
>
> (Moreover I think bad clients is the more likely case of e.g. content
> theft).
>
> > If we continue to support the existence of grids like OSGrid, then we
> > need to think what it means for the users to visit such grids, and how
> > they can visit them securely -- that's all I'm trying to figure out.
>
> They should at least be made aware that there is not one entity running
> it you can sue (well, I don't know the TOS so I don't know if you
> actually could sue somebody).
>
> -- Christian
>
> PS: I know that the OAuth stuff is far away from what would be possible
> right now as it would also mean quite some changes to the client, I am
> mostly mentioning it for discussion purposes and because those are
> standards which are on the rise right now.
>
> >
> >
> > Justin Clark-Casey wrote:
> >> Charles Krinke wrote:
> >>> OSGrid exists with two goals.
> >>>
> >>> 1. Test OpenSim SVN on a regular basis and report results to aid in
> >>> software development.
> >>> 2. Nurture a community.
> >>>
> >>> We need to start by considering that OpenSim splits the asset storage
> >>> between regions and the OpenSim assetServer. So, the OpenSim asset
> model
> >>> is a little different then SecondLife since we already distribute some
> >>> assets between regions and the UGAIM.
> >> I didn't know you were doing this already. Is there anywhere you
> could point to with more details?
> >>
> >>> Are we saying that OSGrid is doing something problematic and
> pertubating
> >>> the OpenSim development? I am confused about the OSGrid comments in
> this
> >>> philosophical discussion. As I see the whole situation, OSGrid is
> >>> testing the mainline trunk SVN from OpenSim in a manner consistent
> with
> >>> the desires of the community.
> >> Not at all. I think the debate is more about how the architecture
> will move forward in the future. As you know,
> >> regions on OSGrid have to be pretty trustworthy so as not to abuse
> the central grid services. This classic architecture
> >> won't go away, but it might be that active development and research
> switches to other architectures (e.g. client side
> >> asset/inventory access, hypergrid), which can be better secured for
> a robust distributed virtual environment.
> >>
> >> OSGrid may want to consider at some point whether it wants to
> migrate or switch to other architectures once these have
> >> matured further. I doubt that this maturity is all that imminent.
> >>
> >> Anyway, I'm probably putting words into Diva's mouth now.
> >>
> >>> Charles
> >>>
> >>>
> ------------------------------------------------------------------------
> >>> *From:* Justin Clark-Casey <jjustincc at googlemail.com
> <mailto:jjustincc at googlemail.com>>
> >>> *To:* opensim-dev at lists.berlios.de
> <mailto:opensim-dev at lists.berlios.de>
> >>> *Sent:* Wednesday, April 15, 2009 8:24:45 AM
> >>> *Subject:* Re: [Opensim-dev] The essence of "grid"
> >>>
> >>> Diva Canto wrote:
> >>> > As I zoom in on issues of trust and security, I'm getting to the
> point
> >>> > where I need a sharp definition of "grid". What is a grid,
> besides being
> >>> > a map/lookup service and a user accounts service?
> >>> >
> >>> > a) nothing more than that
> >>> > b) a trust domain
> >>> >
> >>> > If we choose b) then we need to think about OSGrid-like grids.
> How can
> >>> > we trust that a collection of regions administered by different
> people
> >>> > will behave? Can OSGrid-like grids survive without ToS being signed
> >>> > between the grid operator and the region operators? What if the
> ToS is
> >>> > such that it delegates to the region admins any liability on bad
> things
> >>> > happening in their regions? -- that leaves the user with no central
> >>> > authority to complain, which is as good as not having a trust
> domain.
> >>> >
> >>> > If OSGrid-like grids (i.e. no contracts, or very loose ones;
> just a map
> >>> > service) are to exist, then it's clear that b) doesn't hold in
> general.
> >>> > It means that there can be grids that are simply a collection of
> regions
> >>> > that come together in virtual space, but whose trustworthiness as a
> >>> > whole doesn't exist.
> >>> >
> >>> > The Hypergrid is specifically designed to cross trust
> boundaries. Should
> >>> > the OSGrid-like grids become HG-ed sims that share the same map,
> and let
> >>> > "grids" be, fully, trust domains?
> >>> >
> >>> > You may think I'm getting into philosophy, but this is critical
> for the
> >>> > technical work I'm doing right now related to authentication,
> >>> > server-side vs client-side authority, etc. If we can assume that a
> >>> > "grid" is a uniform trust domain with a central authority,
> things will
> >>> > be simpler in many ways. If not, things will be a bit more
> complicated.
> >>> >
> >>> > Thoughts?
> >>>
> >>> I think that you could adopt b) without having a philosophical problem
> >>> with OSGrid. I would say that even the 'loose
> >>> contracts' on OSGrid are a form of trust. If someone were to abuse
> that
> >>> trust then I be very surprised if they were not
> >>> removed from the grid.
> >>>
> >>> If OSGrid wanted better security by not sharing the current central
> >>> services then perhaps they could stipulate that new
> >>> regions had to connect by Hypergrid rather than the current model
> (once
> >>> the various gaps in Hypergrid are ironed out)?
> >>> Then, in a sense, all the directly connected regions becomes a large
> >>> Hypergrid node in the federation that makes up OSGrid.
> >>>
> >>> >
> >>> >
> >>> > _______________________________________________
> >>> > Opensim-dev mailing list
> >>> > Opensim-dev at lists.berlios.de
> <mailto:Opensim-dev at lists.berlios.de>
> <mailto:Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>>
> >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >>> >
> >>>
> >>>
> >>> --
> >>> justincc
> >>> Justin Clark-Casey
>> >> http://justincc.wordpress.com
> >>> _______________________________________________
> >>> Opensim-dev mailing list
> >>> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
> <mailto:Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>>
> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev
> >>>
> >>>
> >>>
> ------------------------------------------------------------------------
> >>>
> >>> _______________________________________________
> >>> Opensim-dev mailing list
> >>> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev
> >>
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
> --
> COM.lounge GmbH
> http://comlounge.net
> Hanbrucher Strasse 33, 52064 Aachen
> Amtsgericht Aachen HRB 15170
> Geschäftsführer: Dr. Ben Scheffler, Christian Scholz
>
> email: info at comlounge.net <mailto:info at comlounge.net>
> fon: +49-241-4007300
> fax: +49-241-97900850
>
> personal email: cs at comlounge.net <mailto:cs at comlounge.net>
> personal blog: http://mrtopf.de/blog
> personal podcasts: http://openweb-podcast.de, http://datawithoutborders.net
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
More information about the Opensim-dev
mailing list