I think we already have an understanding of what is needed for securing users from malicious hosts: client-side control, that's all. Client has direct control over user agents, user's inventory, IM, social network, etc. The regions stay out of it, they are only simulators of objects and agents. Grider is exploring that design space, and instrumenting OpenSim for it. We're very close to having OpenSim support these kinds of clients.
However, in some cases, the user may want to give control, at least some, to the ... and this is where terminology gets tricky... simulators? "grid"? And why would that be, you may ask. Well, because that server-side (not to get into the choice of words again) may provide some cool stuff if you pass it the control. It may, for example, give you an additional world-specific inventory, or it may open agents for you in interesting 3d spaces, or you won't be able to play whatever game is going on in there unless the server-side has control over some of your data. But even this is *sortof* relatively simple to do, IF we align the concept of VW with the concept of trust domain. OSGrid, however, doesn't do that. So what would it mean for a user to visit OSGrid? With which server would the user's client share authority, if it were to share it? Christian Scholz wrote: > 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 <jjusti...@googlemail.com> >>>> *To:* opensim-dev@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@lists.berlios.de <mailto:Opensim-dev@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@lists.berlios.de <mailto:Opensim-dev@lists.berlios.de> >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev@lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev