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 <[email protected]> > *To:* [email protected]; [email protected] > *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 <[email protected] > <mailto:[email protected]>> > >>> *To:* [email protected] > <mailto:[email protected]> > >>> *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 > >>> > [email protected] > <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> > > >>> > >>> > >>> -- > >>> justincc > >>> Justin Clark-Casey >> >> http://justincc.wordpress.com > >>> _______________________________________________ > >>> Opensim-dev mailing list > >>> [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > >>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> > >>> > >>> > ------------------------------------------------------------------------ > >>> > >>> _______________________________________________ > >>> Opensim-dev mailing list > >>> [email protected] <mailto:[email protected]> > >>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > > _______________________________________________ > > Opensim-dev mailing list > > [email protected] <mailto:[email protected]> > > 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: [email protected] <mailto:[email protected]> > fon: +49-241-4007300 > fax: +49-241-97900850 > > personal email: [email protected] <mailto:[email protected]> > personal blog: http://mrtopf.de/blog > personal podcasts: http://openweb-podcast.de, http://datawithoutborders.net > > _______________________________________________ > Opensim-dev mailing list > [email protected] <mailto:[email protected]> > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > ------------------------------------------------------------------------ > > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
